How Companies Document AI Systems for Audits
An AI audit cannot rely on someone saying, “We tested the system and it looked fine.”
Auditors need evidence showing what the system was designed to do, which version was used, how it was tested and what happened after deployment.
What records help an auditor reconstruct how an AI system was built and operated.
A model card can describe a model. A complete audit trail must also show how the wider system was selected, tested, changed, used and monitored.
Food packaging has an ingredient label.
Aircraft have maintenance records.
The label helps explain what went into a product. The maintenance record shows what happened to it over time.
An AI audit may need both kinds of evidence.
An auditor may need to understand what the system contains, what it was intended to do, how it performed during testing and whether it changed after deployment.
Documentation is not one document
People sometimes imagine AI documentation as a single report written before launch.
In practice, useful documentation is a collection of connected records. Different records answer different questions.
They may include:
- a system description
- an intended-use statement
- model and supplier information
- relevant data records
- test plans and results
- known limitations
- approval decisions
- version and change history
- monitoring reports
- incident records
Not every system needs the same amount of documentation. A consequential system usually needs a stronger evidence trail than a low-risk internal writing assistant.
Start with the intended use
A record of intended use explains what the system was built or selected to do.
It should answer questions such as:
- Who will use the system?
- What decision or task will it support?
- What should it not be used for?
- What information will it receive?
- What actions can it take?
- When is human review required?
This matters because a system cannot be tested meaningfully without knowing its purpose.
A model that performs well as a general writing assistant may still be unsuitable for legal, medical or employment decisions.
What a model card can explain
A model card is a structured description of a model.
Its contents vary, but it may describe:
- the model’s purpose
- supported tasks
- evaluation results
- known limitations
- important conditions of use
- areas where performance may be weaker
A model card can help a company decide whether a model is suitable.
However, it does not automatically describe the complete deployed system.
It may not show which company documents were connected, which prompts were added, which tools the model could use or how employees reviewed its outputs.
Data records need careful wording
AI documentation does not always contain a complete list of every training item.
For large models, the full training mixture can be enormous, complex or partly controlled by an external provider.
Useful records may instead describe:
- data sources or categories
- collection and preparation methods
- quality checks
- known gaps
- usage restrictions
- data used for evaluation
A company deploying an external model may not possess all the provider’s training details.
It should still document what it knows, what it does not know and what additional data it adds to the system.
Testing records show more than the final score
A test result without context can be misleading.
An audit trail should make it possible to understand:
- which system version was tested
- which test cases were used
- what success criteria were chosen
- who reviewed the results
- which failures were found
- what changed after the failures
A single average score may hide important weaknesses.
For example, a system can perform well overall while failing badly on a rare but consequential type of request.
Version history connects decisions to the right system
AI systems change.
The model may be updated. The system prompt may be rewritten. A retrieval database may receive new documents. A safety filter may be added. Tool permissions may change.
Each change can affect behaviour.
A version history helps answer:
- Which configuration was active on a particular date?
- What changed between two releases?
- Were important tests repeated?
- Who approved the change?
This is why traceability matters more than an unrealistic promise that records will never change.
Good records can be corrected when necessary, but corrections should be controlled and visible.
Operational logs show what happened
Design documents explain what a system was supposed to do.
Logs help show what it actually did.
Depending on the system and privacy requirements, logs may record:
- the system version used
- when a request occurred
- whether a tool was called
- whether a safety rule was triggered
- whether a human reviewed the result
- whether the user reported a problem
Logging everything is not automatically better. Logs can contain personal, confidential or security-sensitive information.
A sensible system records what is necessary while applying access limits, retention rules and privacy protections.
Incident records complete the picture
A well-documented AI system can still fail.
When that happens, the organisation should be able to record:
- what occurred
- who was affected
- which system version was involved
- how the problem was detected
- what immediate action was taken
- what longer-term change followed
An incident record is not simply evidence of failure. It can also show whether the organisation learned from the failure.
- What the AI system was intended to do and what limits were known.
- Which version was tested, approved and active at a particular time.
- How changes, incidents and human interventions were handled.
The plain-English takeaway
An AI audit is not a conversation with the model and it is not a generic compliance essay.
It is an attempt to reconstruct the system’s history from reliable evidence.
The strongest documentation connects purpose, data, tests, versions, decisions, logs and incidents. Together, those records make the system more understandable and accountable.
Comments
Post a Comment