Path 03Lesson 5 / 6

Connect obligations to evidence

Separate legal applicability, technical controls, and proof of operation. Build a record that a responsible reviewer can inspect.

Foundation11 minReviewed

Published by How we write

What you will learn

  • Distinguish an obligation, a control, and evidence.
  • Identify who must assess legal applicability.
  • Recognize why generated documentation does not establish compliance.

Begin with the system and its intended use

“We use AI” is not enough information to determine legal obligations. Describe the service, users, data, decisions, jurisdictions, and the organization’s role. Distinguish AI used to develop software from AI used inside the delivered product.

For example, using a coding assistant to implement a fixed calculation differs from deploying a model that evaluates job applicants. Both need an appropriate development process. Their operational effects and applicable obligations can differ.

Ask a qualified legal or compliance owner to assess applicability. The European Commission explains the AI Act’s risk-based framework. Check current law and guidance for the actual use case rather than relying on a remembered deadline. AI Act framework.

Separate four parts of the record

An obligation states what must be achieved. A control describes how the organization addresses it. Evidence shows what happened or what was verified. A decision records who accepted the conclusion and under which conditions.

Consider a fictional customer export. The organization has a policy that managers can export records only for their own organization. A useful record might contain:

PartExample
RequirementRestrict export to the requesting manager’s organization
ControlEnforce organization membership in the server-side query
EvidenceCross-organization denial test for the release commit
DecisionService owner accepts the result; security owner reviews the boundary
Review triggerAuthorization logic or organization model changes

This example illustrates an internal requirement. It is not a claim that one test satisfies a particular law. Keep that distinction in your records.

Treat generated documents as reviewable work

AI can help draft a data-flow description, identify missing fields, or summarize existing evidence. It can also assume a recipient, invent a control, or describe a backup that nobody has tested.

Check each material statement against the system. If a document says that data is encrypted, identify the relevant store, key arrangement, and configuration evidence. If it says that access is reviewed, locate the process and its actual records.

A data protection impact assessment, or DPIA, is about the processing and its effects on people. Under GDPR Article 35, the requirement depends on likely high risk and the processing context. Producing a file with this title does not complete the assessment. GDPR Article 35.

Keep evidence current and proportionate

Tie evidence to a version, environment, and date. A test from an earlier release may not cover a changed authorization path. Define when a material change requires renewed review.

Collect what supports the decision. Avoid retaining full customer records merely to prove that an export test ran. A carefully designed test can use fictional data and record the necessary result.

An effective governance tool connects requirements, work, evidence, and decisions. It does not remove the organization’s responsibility to interpret obligations or operate controls. Evaluate that connection when comparing individual coding tools with a complete delivery system.

Do the exercise

Use the fictional customer export from this lesson. Complete one row with obligation or policy, interpretation owner, control, evidence, and review trigger. Add one unresolved question. Do not fill an unknown legal conclusion with an AI-generated answer.

Download worksheet (Markdown)

Check your understanding

An agent generates a DPIA document. What can you conclude?

Sources & further reading

Related reading from Taiga