Compliance by Design

Many AI projects treat compliance like the final folder before go-live: check privacy, collect a few screenshots, describe risks, sign an approval — done.

That is exactly where the problem begins.

Documentation created only after the fact can often do little more than tell a plausible story about what supposedly happened. It cannot reliably prove which model version actually ran, which data was processed in which zone, which tests had passed before approval, who authorized an exception, or why a later change did not trigger a new review.

Professional AI governance therefore needs a different approach:

Compliance is not an archive folder at the end of a project. Compliance is an architecture that defines which evidence must arise during the work, who owns it, which controls actually enforce rules, and what must not proceed when evidence is missing.

That is Compliance by Design.

Compliance by Design begins before the first production run

With conventional documentation, teams work first and describe what happened afterwards. With Compliance by Design, critical workflows start only after several questions have been answered:

Which regulatory or internal requirement is relevant? Which concrete control satisfies it? Who owns that control? Which evidence must be generated automatically or manually? Which system, model and artifact version is that evidence bound to? When is it reviewed? What blocks release? When must the evidence be renewed? How long may or must it be retained?

This moves compliance out of the realm of memory and into system design.

Documentation is not the same as compliance

A project can be beautifully documented and still be non-compliant.

Conversely, a system may satisfy a substantive requirement yet still struggle later because the organization cannot demonstrate how it complied.

Five concepts therefore need to be separated:

The report is not the control. And the control is not automatically proof of its own effectiveness.

The key shift: from post-hoc protocol to operational control system

In mature AI projects, the project-management or governance system should not be populated after the work is already complete.

Risks, decisions, gates, exceptions, evidence and releases should arise during the actual work.

That fundamentally changes evidence quality.

When an agent starts a work step, the run can already be linked to a task, a data class and an allowed tool policy. When a gate is reached, the required evidence is already defined. When a model changes, the change can create a new review obligation. When a critical test fails, the downstream release remains blocked.

The result is not an audit diary but an executable control structure.

Evidence by Construction

The strongest evidence is often evidence that does not need to be produced as a separate bureaucratic exercise.

If a system automatically records for each critical run the model and version, the active policy, the data class, the tools invoked, the artifact produced, the evaluation version applied and the gate decision that followed, then evidence becomes a by-product of a correctly built process.

This can be described as Evidence by Construction.

The alternative is to reconstruct events weeks later from chats, memory and screenshots. That approach does not scale to agentic systems.

Compliance is a chain, not a document

A robust compliance chain can look like this:

Requirement → Risk → Control → Execution → Evidence → Review → Decision → Version → Monitoring

Every link serves a different purpose.

Without a requirement, nobody knows why the control exists. Without a risk statement, the measure may be disproportionate. Without a control, compliance remains declarative. Without evidence, effectiveness cannot be demonstrated. Without versioning, it is unclear which system state the evidence covered. Without monitoring, the decision silently becomes stale.

The true unit of compliance is therefore not the PDF but the linked evidence chain.

The compliance stack for AI projects

A layered stack is useful in practice.

1. Scope & Classification

What role does the organization play? Which system, use case and user group are involved? Which jurisdictions and sector rules matter? Is this even a regulated high-risk case, or a materially simpler scenario?

2. Risk & Impact

Which harms or fundamental-rights impacts are realistically possible? Which data risks exist? Which persons or groups may be affected? Where are mistakes reversible, and where are they not?

3. Control Design

Which technical and organizational controls address those risks? Examples include data zones, tool permissions, gates, human oversight, rate limits, exception rules and approval workflows.

4. Operational Evidence

Which logs, test results, reviews, decisions and versions actually arise in operation?

5. Technical Documentation

How are purpose, architecture, relevant versions, dependencies, data flows, tests, limitations and operating conditions documented coherently?

6. Change & Lifecycle Governance

Which changes trigger re-testing, new approvals, impact assessments or a re-evaluation of risk classification?

7. Monitoring & Incident Response

How does the organization detect changes in performance, risks, providers, data or user behavior after go-live?

The stack makes the core point visible: compliance does not begin with archiving. It begins with scope and design.

Classify first, document second

A common failure mode is maximal documentation without prior risk classification.

That creates two problems. First, harmless workflows inherit unnecessary bureaucracy. Second, the sheer mass of documents can obscure the evidence that actually matters.

A risk-proportionate approach is more professional:

Describe the use case. Determine organizational role and responsibility. Identify data classes and affected groups. Check regulatory scope. Evaluate risk level and reversibility. Derive control and evidence depth from that result.

More documentation is not automatically more compliance. Better mapping is more compliance.

Provider and deployer are not the same

Under the EU AI Act, role is critical.

An organization that develops a high-risk AI system and places it on the market under its own name can have different obligations from an organization that deploys an existing system. Importers, distributors, authorized representatives and other actors can also matter.

Data-protection roles are structured differently again: controller and processor are not synonyms for provider and deployer.

A compliance plan therefore needs a Role Map at the beginning.

Without it, teams can create the wrong documentation for the wrong obligation.

The current legal baseline is itself a project artifact

Compliance documentation should version not only the system but also the regulatory baseline used for decisions.

That matters especially in fast-moving AI regulation. As of August 2026, the AI Act applies generally from 2 August 2026, while after the AI Omnibus entered into force in 2026, rules for many stand-alone high-risk systems apply from 2 December 2027 and rules for high-risk systems embedded in regulated products apply from 2 August 2028.^[1]

A project should therefore record:

Which legal version was reviewed, on which date, which classification followed from it, which guidance or standards are still pending, and when the next legal review is due.

“We checked that once” is not a sufficient control.

The dangerous illusion of one universal retention period

Retention is another area where simple numbers are misleading.

A common shorthand is: “AI project documentation must be kept for X months.” There is no single general rule like that.

Different AI Act obligations carry different retention periods. For providers of high-risk AI systems, Article 18 generally requires certain documentation to remain available for ten years after the system is placed on the market or put into service.^[7] Article 19 requires automatically generated logs under a provider’s control to be kept for at least six months, unless other Union or national law provides otherwise. Article 26 contains a corresponding at-least-six-month rule for relevant logs under the deployer’s control, again subject to other applicable law.^[8]

Data-protection, employment, financial, health and other sector rules may create different requirements.

The implication is simple:

Retention has to be determined by artifact and legal basis.

One generic “compliance archive period” is usually too coarse.

The Compliance Matrix

One of the most effective structures turns abstract obligations into concrete project objects.

The matrix prevents three common failures: ownerless obligations, controls without evidence, and documents without an update trigger.

The Minimum Viable Evidence Pack

Not every project needs a regulatory dossier at the depth required for a high-risk system.

For an ordinary professional AI workflow, however, a Minimum Viable Evidence Pack can be useful. This is not a statutory minimum; it is a methodological baseline:

System Card with purpose and limits. Data-flow and data-classification map. Model/provider/version registry. Risk & Decision Log. Eval record for critical quality criteria. Gate/release record. Change log. Incident log. Ownership and escalation path.

This avoids over-regulating small projects while preserving reconstruction and accountability.

System Card: purpose as a control object

A System Card should do more than describe the product.

At minimum, it should define:

Intended use, non-intended use, user groups, relevant data classes, allowed actions, known limitations, critical dependencies, system owner and review date.

These fields are not static.

If a team turns an internal writing assistant into a system used for applicant screening, that is not a minor feature change. The use case has changed fundamentally — and potentially the entire regulatory scope with it.

Data Map: more than “What data do we have?”

A compliance-capable data map should describe more than data sources.

For relevant flows, it should capture:

Origin, purpose, sensitivity, legal and policy basis, storage location, transfer zone, access roles, retention, deletion logic and downstream recipients.

In hybrid AI architectures, this makes visible whether an apparently local workflow still exports data through telemetry, retrieval, debugging or external tools.

Risk and impact assessment must precede the effect

An impact assessment written only after deployment has missed its most important function.

Its purpose is not merely to describe effects that have already happened, but to identify plausible impacts before a critical use and design controls around them.

That principle exists in both data protection and the AI Act. Under the GDPR, a data protection impact assessment is generally required before processing where the processing is likely to result in high risk. The AI Act requires certain deployers of certain high-risk systems to perform a fundamental-rights impact assessment before deployment.^[9]

That does not mean every AI use case automatically needs a formal FRIA or DPIA.

But every professional project benefits from the question:

Which effect do we need to understand before we make this system state productive?

Controls must connect to real system boundaries

A policy in a PDF controls nothing until it is translated into an effective process.

Examples:

“No sensitive data to external models” → the data router blocks defined classes. “No publication without approval” → the publishing tool requires a gate token. “Only evaluated model versions” → deployment accepts only approved registry versions. “Exceptions require authorization” → an exception record needs an owner, rationale and expiry.

This is the bridge between compliance documentation and compliance engineering.

No Evidence, No Release

For critical artifacts, a simple rule should apply:

No evidence, no release.

That does not mean every minor text draft needs a compliance officer.

It means that wherever the project has defined a control requirement, the downstream state is reachable only when the required evidence packet exists.

A release gate can require, for example:

Eval passed, data approval valid, model version registered, known risks accepted, Human Authority assigned, rollback available.

Compliance then becomes a state-transition rule, not a wish.

Gate evidence must be bound to a state

Approval without version reference is dangerous.

“Approved on 12 August” says little if the prompt, model, data basis and tool permissions changed afterwards.

A robust approval should therefore reference at least:

System or release ID, model version, relevant policy version, eval version, data and context state, decision, decision-maker, timestamp and validity conditions.

When a defined condition changes, the approval should become stale.

Change Management is Compliance Management

AI systems change rapidly.

New model version. New provider. New system prompt. Additional data source. New user group. More tool permissions. Higher autonomy. Different output channel.

Any one of these can invalidate part of the previous evidence.

Projects therefore need Change Classes.

Class A — cosmetic

No material effect on function, data or risk. Record the change, but no full review.

Class B — functional

Function or behavior changes. Run targeted re-evals and update relevant documentation.

Class C — material risk change

Data class, user group, effect domain, tool permissions, autonomy or critical dependencies change. Trigger a new risk/compliance review and, where required, a new impact assessment.

The concrete classification is project-specific. The mechanism is what matters: change automatically creates a review question.

Versioning must extend beyond code

Git alone is not enough.

At minimum, AI projects should make these objects versionable or uniquely identifiable:

System description, prompt and instruction set, model and provider configuration, retrieval sources, tool schema and permissions, evaluation suite, policy rules, data classifications, approval and technical documentation.

Otherwise a strange situation emerges: the code is perfectly versioned, but nobody knows which policy and model actually governed the production release.

Compliance needs owners

Ownerless controls die quietly.

Every material control needs at least:

Control Owner — responsible for function and maintenance.

Evidence Owner — ensures that evidence is generated and retrievable.

Reviewer — evaluates effectiveness or appropriateness.

Accountable Authority — accepts residual risk or blocks release.

In small teams, several roles may sit with one person. The role logic should still be explicit.

“IT usually handles that” is not an accountability structure.