Before You Ask If Your AI Product Complies, Build an AI System Brief

Most AI teams begin compliance work with the wrong question:

Does our product comply with the EU AI Act?

It sounds reasonable. But a lawyer, compliance specialist, enterprise customer, or assessment tool cannot answer it responsibly without first understanding what the product actually does.

They need to know:

• what the AI system is intended to do;
• who uses it;
• who is affected by its outputs;
• what decisions it influences;
• which models and vendors are involved;
• what data it processes;
• where human review exists;
• what evidence the company can provide.

Without those facts, “Are we compliant?” is not yet a legal question.

It is an incomplete product-discovery task.

Before building a large compliance program, create a concise AI system brief.

This article is for general informational purposes and is not legal advice.

Compliance starts with product facts

Companies often describe themselves as having “an AI product.”

In practice, one SaaS application may contain several separate AI-enabled systems or features:

• a customer-facing chatbot;
• a summarisation tool;
• a recommendation engine;
• a fraud-risk score;
• a document classifier;
• a candidate-ranking feature;
• an internal support assistant;
• an agent that can update records or send messages.

These features may have different purposes, users, risks, and technical dependencies.

A chatbot that answers product questions is not necessarily analysed in the same way as a system that ranks applicants for employment.

Even when both features use the same underlying model, their legal and operational context can be very different.

The first useful step is therefore not assigning one compliance label to the entire company.

It is identifying the individual AI systems inside the product.

Start with intended purpose

The intended purpose is one of the most important fields in an AI system brief.

Avoid vague descriptions such as:

We use AI to improve productivity.

That does not explain what the system actually does.

A better description would be:

The system analyses incoming customer-support tickets, assigns a suggested category, and drafts a proposed response for review by a support agent.

That statement reveals several important facts:

• the system analyses customer communications;
• it classifies tickets;
• it generates text;
• a human is expected to review the output;
• the result supports a business process rather than independently completing it.

Compare it with:

The system analyses job applications, assigns each candidate a suitability score, and determines which candidates are shown to a recruiter first.

Both products may be described as “AI assistants.”

But the second system influences an employment-related process involving natural persons.

The label “AI assistant” tells us very little.

The intended purpose tells us much more.

The AI Act’s official Article 6 classification rules focus on the system’s intended purpose, the use case, and whether the output materially influences decision-making.

Identify the people involved

An AI system brief should distinguish between at least three groups.

Users

The people who directly operate or interact with the system.

Examples:

• support agents;
• recruiters;
• administrators;
• consumers;
• developers.

Affected people

The people whose opportunities, access, treatment, or experience may be influenced by the output.

Examples:

• job applicants;
• borrowers;
• students;
• patients;
• employees;
• customers.

Responsible people

The people expected to review outputs, handle incidents, approve changes, or respond to complaints.

These groups are not always the same.

A recruiter may use a ranking tool, job applicants may be affected by it, and an HR manager may be responsible for oversight.

Documenting these relationships makes later risk and governance discussions much more concrete.

Record what the output influences

Do not stop at describing what the model produces.

Document what happens next.

For example:

The system produces a score from 0 to 100.

That is technically correct but incomplete.

A more useful explanation is:

The score determines the order in which applications are reviewed. Candidates below a threshold are not automatically rejected, but recruiters rarely review them under the current workflow.

The second version explains the practical influence of the system.

Ask:

• Is the output informational?
• Is it a recommendation?
• Does it rank or score people?
• Does it determine eligibility?
• Does it automatically trigger an action?
• Can a person override it?
• Does the reviewer realistically have enough time and context to evaluate it?
• What happens when the model is uncertain?

A system may be described as “advisory” while still having a major practical effect on decisions.

The workflow matters as much as the interface label.

Write down your role hypothesis

The AI Act assigns responsibilities to different operators, including providers, deployers, importers, and distributors.

The official definitions are available in Article 3 of the AI Act.

A company that uses a third-party model is not automatically “only a deployer.” The analysis may depend on how the resulting system is developed, branded, placed on the market, and used.

Your brief should therefore contain a role hypothesis rather than a confident label with no explanation.

For example:

Potential role:
Provider of the customer-facing AI system

Confidence:
Medium

Reason:
We define the intended purpose, integrate the model into our
application, and offer the resulting system under our own name.

Missing facts:
Whether the customer materially changes the system's intended purpose.

Legal confirmation required:
Yes

Documented uncertainty is more useful than an unexplained green checkmark.

Map the technical dependencies

Most AI SaaS products depend on several external components.

A system brief should identify:

• model providers;
• hosting providers;
• vector databases;
• analytics tools;
• observability platforms;
• data-labelling services;
• document-processing services;
• speech or image APIs;
• open-source models and libraries.

For each dependency, record:

• what it provides;
• what data is sent to it;
• where processing occurs;
• how long data is retained;
• whether customer data may be used for training;
• how model updates are communicated;
• what technical documentation is available;
• what happens if the vendor changes or retires a model.

Using a well-known model provider does not answer questions about your own product.

Your application still has its own:

• intended purpose;
• interface;
• integrations;
• users;
• data flows;
• safeguards;
• failure modes.

The complete system is what customers and affected people experience.

Capture the data flow

A useful data-flow description does not need to begin as a complex architecture diagram.

A simple table may be enough:

Stage	Data	Destination	Purpose	Retention
User input	Support message	Application server	Create ticket	12 months
Model request	Ticket text	Model API	Draft response	Provider-specific
Logging	Prompt and output	Observability platform	Debugging	30 days
Review	Draft and edits	Internal dashboard	Human approval	12 months

The goal is to make hidden processing visible.

This often reveals important questions:

• Are personal details included in model requests?
• Are prompts stored by external providers?
• Can sensitive fields be removed?
• Are logs accessible to too many employees?
• Does deletion cover every vendor?
• Can the company reproduce which model produced an output?
• Can the company identify which system version was active during an incident?

These questions matter for privacy, security, procurement, debugging, and incident response even before a specific AI Act obligation is confirmed.

Document human oversight honestly

Many product descriptions contain the phrase:

A human is always in the loop.

That statement is often too vague to be useful.

A system brief should answer:

• Who is the responsible human?
• At which point do they review the output?
• What information do they see?
• Can they reject or modify the result?
• Are they trained to identify failures?
• Are overrides recorded?
• What happens under high workload?
• Can an affected person request human review?
• Who handles escalations?

A confirmation button does not automatically create meaningful oversight.

If employees approve hundreds of outputs per hour without enough context to evaluate them, the formal presence of a human may not reflect the real workflow.

Describe what happens in practice, not only what the interface allows in theory.

For high-risk AI systems, human-oversight requirements are addressed specifically in Article 14.

Build a lightweight evidence pack

Compliance is not only about saying that controls exist.

It is about being able to show them.

A lightweight evidence pack may include:

• the AI-system inventory;
• a one-page brief for each system;
• model and vendor inventory;
• intended-purpose description;
• data-flow description;
• user disclosures;
• human-oversight procedure;
• risk and limitation notes;
• testing records;
• logging approach;
• incident and escalation process;
• unresolved questions for legal counsel.

Not every item is a universal legal requirement for every AI system.

That distinction matters.

The AI Act sets specific requirements for high-risk systems, including:

• risk management;
• technical documentation;
• record-keeping;
• human oversight;
• accuracy, robustness, and cybersecurity.

A lower-risk product may still maintain similar materials because they help with enterprise procurement, security, customer trust, debugging, or future readiness.

Label each item in the evidence pack as one of the following:

• Confirmed legal requirement
• Recommended readiness practice
• Customer or procurement requirement
• Requires legal confirmation

This prevents a readiness document from pretending to be a legal opinion.

Prepare for transparency at the product level

Article 50 contains transparency obligations for certain AI systems, including some systems that interact directly with people and some systems that generate or manipulate content.

According to the Commission’s official AI Act implementation timeline, these transparency obligations apply from 2 August 2026.

For a product team, preparation may involve questions such as:

• Does the user know they are interacting with AI?
• Is the disclosure shown before or during the first interaction?
• Is it clear on mobile?
• Is generated content labelled where required?
• Does the interface overstate human involvement?
• Does the disclosure remain accurate when the workflow changes?
• Is the information accessible and understandable?

This is not only a policy-document task.

It is a product-design task.

A disclosure hidden in a long terms-of-service page may not reflect what the user actually experiences during the interaction.

Include known uncertainty

An AI system brief should not pretend that every classification question has already been resolved.

A useful section might look like this:

Potential classification:
Possible Annex III high-risk use case

Confidence:
Low

Reason:
The system is used in an employment workflow, but it may perform
only a preparatory task and does not automatically reject candidates.

Missing facts:
How recruiters use the ranking in practice and whether the output
materially influences who advances.

Legal confirmation required:
Yes

This gives a lawyer or specialist something concrete to examine.

It also prevents internal assumptions from slowly turning into “facts” merely because they appeared in an old spreadsheet.

A one-page AI system brief template

A lightweight brief can contain the following sections.

1. System identity

• system or feature name;
• owner;
• version;
• current status;
• last review date.

2. Intended purpose

• what the system does;
• what it is not intended to do;
• prohibited or unsupported uses.

3. Users and affected people

• direct users;
• affected groups;
• responsible reviewers.

4. Output and influence

• type of output;
• downstream decisions;
• automation level;
• override process.

5. Models and vendors

• external providers;
• model versions;
• infrastructure dependencies;
• known update process.

6. Data

• input data;
• personal or sensitive data;
• storage and retention;
• processing locations.

7. Oversight

• responsible human;
• review points;
• escalation process;
• appeal or correction process.

8. Evidence

• testing records;
• logs;
• policies;
• system documentation;
• incident history.

9. Preliminary hypotheses

• likely operator role;
• possible risk category;
• possible transparency obligations;
• unresolved questions.

10. Review history

• reviewer;
• date;
• product changes since the previous review.

This document does not prove compliance.

It creates the factual foundation needed for a serious assessment.

Automated tools can help without inventing certainty

An automated checker can help a team:

• organise product facts;
• identify missing information;
• surface potentially relevant provisions;
• prepare questions for counsel;
• create a preliminary readiness checklist.

It should not claim to provide a definitive legal classification from a few form fields.

The European Commission provides an official beta EU AI Act Compliance Checker. Its disclaimer states that the results are informational, are not legal advice, and do not represent the Commission’s assessment of a company’s situation or obligations.

That is the right model for responsible tooling.

A useful system should expose assumptions, uncertainty, and missing facts rather than hide them behind a confident score.

The best legal handoff begins before the legal call

Compare these two messages.

Message A

We use AI. Can you tell us whether we comply with the AI Act?

Message B

We provide a candidate-ranking feature used by EU employers. The ranking determines which applications recruiters review first, but it does not automatically reject candidates. We use a third-party model, store outputs for 30 days, and require recruiter confirmation. Here is our intended purpose, data flow, oversight process, vendor list, and the five classification questions we have not resolved.

The second message does not replace legal advice.

It makes legal advice more efficient.

The lawyer can focus on questions that require legal interpretation instead of spending the first part of the engagement reconstructing the product from screenshots, Slack messages, sales copy, and incomplete technical explanations.

Final thought

AI compliance does not begin with a checkbox.

It begins with a clear description of the system.

Before asking whether an AI product complies, document:

• what it does;
• who it affects;
• what decisions it influences;
• which vendors and models it relies on;
• how people review its outputs;
• what evidence exists;
• what remains uncertain.

That brief remains useful even when the final legal conclusion changes.

It can support:

• legal review;
• enterprise procurement;
• investor diligence;
• security assessments;
• product governance;
• incident response.

The goal is not to replace a lawyer.

The goal is to give the lawyer — and your own team — something concrete to review.

---

About the project

I am building ActBrief, a project that helps AI teams organise product facts, documentation gaps, effective dates, and questions for qualified counsel.

ActBrief produces preliminary readiness material. It does not provide legal advice or a definitive compliance determination.

Disclosure: I used an AI writing assistant to help structure and edit this article. The product observations, source review, conclusions, and final editorial decisions are my own.