Technical documentation should travel with the released AI system

EU AI Act technical documentation for a high-risk system should explain the system, development, intended purpose, performance, risks, controls, monitoring, and changes well enough for the applicable assessment. Article 11 requires providers to prepare it before placing the system on the market or putting it into service and keep it current.

The minimum content connects to Annex IV and any amended or sector-specific requirements. A generic model card or architecture diagram can contribute evidence. Neither artifact represents the complete file.

This article is a preparation method and needs legal confirmation for the exact system.

Article 11 applies to high-risk provider documentation

Start with role and classification. Article 11 sits in the requirements for high-risk AI systems and addresses provider documentation. A deployer may need the provider's information for its own duties, but should not copy Article 11 into every AI tool checklist as a universal obligation.

Where the system is connected to covered product legislation, documentation may be combined with the product file under the conditions in the Act. SMEs have provisions for a simplified form. Confirm current templates and post-Omnibus changes before use.

Build the file from nine evidence sets

1. System identity: name, version, provider, architecture, interfaces, dependencies, and environments.
2. Intended purpose: users, affected people, designed use, prohibited use, instructions, and operating context.
3. Development: methods, design choices, upstream models, components, data, evaluation, and change control.
4. Data: sources, characteristics, governance, preprocessing, quality, access, retention, and limitations.
5. Performance: metrics, thresholds, test populations, known limits, foreseeable misuse, and uncertainty.
6. Risk and controls: risk management, human oversight, cybersecurity, logging, accuracy, and failure behavior.
7. Release evidence: acceptance cases, denied cases, revision, approval, conformity activity, and residual limits.
8. Operation: monitoring, incidents, corrective action, support, rollback, continuity, and post-market evidence.
9. History: material changes, reasons, affected evidence, reviewer, and retirement record.

Use an index that points to controlled source artifacts. Duplicated facts drift.

Separate public transparency from regulatory evidence

A public system card can explain capabilities, limitations, providers, data behavior, and contact points. It should be readable and appropriately limited for security and confidentiality.

The regulatory technical file can contain deeper design, evaluation, risk, and control information. Some parts may be commercially sensitive or restricted. Decide which artifact owns each fact and how updates propagate.

A marketing page should never be the source of truth for model versions or conformity evidence.

Bind claims to tests and versions

Every material claim should point to evidence.

“Users cannot access another project” needs an authorization design and denial test. “Human oversight is supported” needs the interface, instructions, intervention cases, and reviewer role. “Duplicate actions are prevented” needs an idempotency rule and replay test.

Attach results to the code revision, configuration, data version, model route, and environment. A passing test against one model or source scope may expire after a change.

What the Skybridge system card makes reviewable

Skybridge maintains a system card covering intended users, capabilities, model providers, approval doctrine, infrastructure, data behavior, operating boundaries, and governance. It is supported by hundreds of dated changelog entries, separate environments, manual production promotion, incident records, and provider inventories.

Those artifacts create a strong foundation. Current Compsia strategy and the production cockpit translate product-wide language into release-specific scope, evidence, and control ownership. The release-specific documentation index connects each implemented control, test, and accepted operating boundary to the exact version.

The release-specific documentation index records the status and evidence of every control. This keeps the technical file synchronized with the system actually approved for production.

Maintain the file through change and incident

Set change triggers for intended purpose, model, data, user group, performance threshold, integration, authority, risk control, and provider. The change owner identifies which evidence becomes stale before release.

After an incident, add the affected versions, observed behavior, root cause, correction, verification, and wider class review. Skybridge's environment incident led to an audit of 11 scripts and one additional correction. The technical file should show the class-level response, not only the first patch.

Assign an owner for each evidence set. Product owns intended purpose and instructions. Engineering owns architecture and released configuration. Data owners explain sources and quality. Security owns the threat and control record. Operations owns monitoring, support, and incidents. Legal determines the applicable duties and reviews claims. One documentation coordinator can maintain the index without inventing facts for every team.

Automate the mechanical evidence. Continuous integration can capture a code revision, dependency inventory, test result, and image reference. Deployment can record environment and time. Model configuration can produce a route snapshot. Keep human judgment visible for purpose, limitations, risk acceptance, and affected people. Automation should reduce copying while preserving accountable decisions.

Test the file by giving it to a reviewer who did not build the system. They should be able to identify the accepted version, reproduce key tests, find known limitations, and trace a material change. Missing answers create an evidence backlog before release.

The AI Act logging guide explains how runtime evidence supports this lifecycle.

Technical-documentation questions

Is a model card the same as Annex IV documentation?

No. A model card can supply relevant information. Annex IV covers the high-risk AI system and requires a broader evidence set.

Must every AI system have Article 11 documentation?

Article 11 is a high-risk-system provider requirement. Other systems still benefit from proportionate system records and may face other duties.

Can documentation be generated automatically?

Pipelines can capture versions, dependencies, tests, and configurations. Humans still need to explain purpose, assumptions, risk decisions, limitations, and the meaning of change.