AI documentation for software certification in Korea

Choose where drafting can help

Start with explaining implemented features or aligning terminology across existing documents. Implemented code is not automatically an approved requirement, and it cannot establish every user environment or operational responsibility. Identify your target certification, product version, documents, and reviewers first. Confirm supported documents and service terms during consultation.

• Product context: describe intended users, intended use, and operating conditions.
• Baseline materials: align source code, existing documents, and actual test and operational records.
• Open questions: separate undecided requirements from claims that lack evidence.

GS certification: product descriptions and user manuals

For GS preparation, check that feature descriptions and instructions match the actual product. A product description can cover purpose, features, components, operating environment, and installation conditions. Review user manuals in the order users perform tasks. Even a draft based on implementation needs checks of installation steps, interface labels, error guidance, and support information in the actual environment. Saying a feature works does not establish test evidence.

• Describe limitations alongside features.
• Follow installation, configuration, and usage instructions on the relevant version and fill in missing steps.
• Keep checklist questions distinct from recorded inspection results.

Medical software: connect requirements to tests

For medical device software and SaMD, start with intended use and product scope. Review the connections between requirements, design, risk management, verification plans, and actual test records. Source analysis can help explain implementation and structure; it does not decide whether a medical intended use is appropriate or a risk is acceptable. Responsible team members or optional specialists must review scope and matters requiring professional judgment.

• Requirements: state expected behavior and conditions that can be checked.
• Design and risk: examine how implementation, relevant risks, and controls relate to requirements.
• Verification: distinguish planned tests from executed tests and base results on actual records.

An illustrative traceability record

This fictional example explains relationships; it is not evidence of implementation or a passed test. For ‘REQ-001: Do not proceed when a required input is empty,’ reviewers could link ‘DES-001: Input validation,’ a relevant risk and control, and ‘TEST-001: Check missing required input.’ A completed set of links is useful only if the content and evidence agree.

• Leave the test as ‘not executed’ until it runs; do not invent a result or pass status.
• After execution, check the tested version, conditions, actual results, and location of supporting records.
• When a requirement changes, review its effects on linked design, risk, and test items.

Security preparation: policies are not operational evidence

For ISMS and other security or cloud preparation, document management scope, responsibilities, policies, and procedures as they operate in your organization. A policy requiring regular access reviews does not prove a review occurred. Approval records, inspection histories, and corrective action records must come from actual activities. Separate what code can show from organizational matters such as personnel, access, and operational management to make gaps visible.

• Policy: the principles and responsibilities the organization commits to.
• Procedure: who performs an activity and under which conditions.
• Evidence: records of actual activity, which AI cannot fabricate as a substitute.

Source material → draft → human review → maintenance

Begin with product context and readiness, then agree on the scope of any detailed materials to share. After source analysis produces a draft, product owners confirm intended use and feature descriptions. Development, testing, and operations owners provide the relevant evidence. Incorporate review comments and maintain documents as the product changes. New features or environments can affect requirements and test materials as well as descriptions.

• Draft: mark unconfirmed statements as questions to resolve.
• Review: identify both the author and the person responsible for confirming the facts.
• Maintain: make the documented product version clear and assess changes.

Separate document service fees from specialist support

Specify document creation and management costs KRW 300,000 per month. Your team prepares its documents and can separately choose expert review or consulting where needed. Expert services are quoted by scope; certification body testing and assessment fees are also separate. Confirm supported documents, service terms, and VAT treatment during consultation. Draft generation does not provide automatic approval or guarantee certification. The relevant body conducts final testing and assessment and makes certification or authorization decisions.

Frequently asked questions