AI Traceability and Audit Trail Documentation
AI Traceability Documentation, One Audit Trail
AI traceability documentation is one audit trail across your tools. Eicra Soft Limited is a Dhaka-based company that builds that trail, system by system, at a fixed price per system. It connects every AI decision to a system version, the model and data versions behind it, the tests run on it and who approved it. Your named owner, the person on your side who approves each record, signs every one.
Stop after any step; each one ends in a signed record. We start with the one AI system whose evidence would take longest to find if a customer, an auditor or a regulator asked tomorrow: the scoring model, the support chatbot, the vendor model nobody versioned. Where each record lives is mapped, the links that are missing are listed, and the trail is priced from your own figures.
You get a written verdict naming one of five starting points: an evidence map, one system’s audit trail, approval and change records, a law-specific file with the trail under it, or a governance inventory. If nothing is in scope, you stop here and keep the gap review.
30 minutes 01 Scope · free call
2 weeks 02 Diagnose · $1,500 evidence review, half credited
4 weeks 03 Pilot · $4,000, one system’s trail
Per system 04 Production · from $6,000 per system
Quarterly 05 Managed Ops · quarterly reconciliation
What is included in AI traceability documentation?
AI traceability documentation hands over six records: an evidence map, a version and lineage record, test and evaluation evidence, approval records, change records, and a retention and access schedule with the handover. Every record cites the identifiers the others use so a reviewer can walk from a decision back to its data without asking anyone.
The evidence map
Every evidence object for the system is listed, from code, model and dataset versions to test reports, approvals, change tickets and logs. Each entry names where it lives, its owner and its identifier. It becomes the index every other record points to, so nothing has to be found twice.
Version and lineage record
One model and data lineage record per release, the provenance behind every output, names the system, model and dataset versions behind it, with their sources and preparation steps. It also names the vendor model it depends on, readable without a pipeline. Each release gets its own record, so any decision maps to exact versions.
Test and evaluation evidence
Every test run, evaluation result, bias check and human review is tied to the version it examined, including results from AI model testing. Each carries its acceptance threshold and the person who read the result. Reports scattered across tools are pulled into one place, each naming the release it tested.
Decision and approval records
Each record shows who approved a release, model change or dataset swap, when, and against which version and evidence. Approvals from chat and email, including human-in-the-loop review decisions, move into the trail with their dates. Each approval names the version and evidence it covered, and your named owner makes it final.
The change records
A change log per system says what changed between two versions, why, who asked, who approved and which tests were re-run. A shift in behaviour is then explained, not remembered, and a change that caused a failure links to its AI incident documentation. Each entry cites the identifiers of both versions, so a reviewer can follow it without asking anyone.
Retention, access and handover
A retention schedule and access rules are set for each evidence object, with versioning duties named on your side. A handover session follows, then optional quarterly reconciliation. Under Managed Ops, every release since the last review is checked against its lineage record, tests and approvals.
Not included: Logging systems or machine learning operations (MLOps) tooling · running your pipelines · certification, or calling any system audit-ready.
Which AI traceability record comes first?
AI traceability documentation links every AI decision to the release, model version and dataset version behind it, plus the tests and approvals on each. It rests on four records, indexed by an evidence map: a lineage record (the spine), test evidence, approval records and a change log. The evidence review shows which one you lack first. All four are part of our AI services.
The NIST glossary defines traceability as a “discernible association among two or more logical entities”. Forward traceability follows a dataset to every model and release that uses it; backward traceability walks from a decision back to its evidence. An AI audit trail, also called an ML audit trail, is the linked record that makes both possible. AI can draft these records from code, logs and metadata; a person checks and signs each one.
A lineage record
Start here when nobody can say which data version trained the model behind a decision. One record per release links that decision to its model and dataset versions.
Linked test evidence
Start here when test reports sit in several tools and none names a release. Each result is tied to the exact version it tested, with its pass threshold and reviewer.
An approval record
Start here when releases are approved in chat and nobody can show who said yes. Each sign-off is dated and tied to the version and evidence it approved.
A change log
Start here when a live system’s behaviour has shifted without a paper trail. Each entry records what changed, why, who approved it and which tests were re-run.
How long does an AI traceability pilot take?
An AI traceability documentation pilot takes four weeks for one system: it links a decision to its release, the release to its model version and the model to its datasets, then attaches tests and approvals. The sample below is a credit-scoring model whose records lived in a repository, a model registry, a ticketing tool and email.
The five steps, with time and price
| # | Step | Time | Price | What you receive |
|---|---|---|---|---|
| 01 | Scope | 30 minutes | Free | The system, who wants evidence and which tools hold it |
| 02 | Diagnose | 2 weeks | $1,500, half credited to the pilot | Every link marked present, partial or missing |
| 03 | Pilot | 4 weeks | $4,000, fixed | One system’s audit trail, signed by your owner |
| 04 | Production | Per system | From $6,000 per system | Further trails, retention rules and a change procedure |
| 05 | Managed Ops | Quarterly | Optional, cancel any quarter | Releases reconciled and the change log signed |
Pilot log · credit-scoring model
The trail at that step · its result
Scope signed
The system, its releases and its owner.
Lineage recordTest evidenceApproval recordChange log
| Scope item | Sample system |
|---|---|
| System | Credit-scoring model |
| Releases | 6 in scope |
| Evidence objects | 4 |
| Links to check | 22 |
| Owner | Named |
4
Evidence objects in scope1 system · 6 releases
Evidence located
Where each record lives today.
RepositoryModel registry5 test reports4 approval emails
14 of 22
Links present before any work8 missing, listed with owners
Links built
One lineage record per release.
Decision→Release→Model version→Dataset version
Tests attachedApprovals attached
8
Missing links requested and closedfrom the named owners
Owner sign-off · a person signs
Your owner follows every link.
Decision→Release→Model version→Dataset version
Owner sign-offEvery link resolves, and the approval is logged with its date.
22 of 22
Links that resolveapproval logged with date
Handed over
The trail stays in your own systems.
Trail approved→Your systems→Change log open→Retention dated
Handed overchange log open · retention schedule dated
Select a step, or a number below, to see the trail at that stage
Every quarter, each release since the last review is checked against its lineage record, tests and approvals.
Illustrative example. Yellow is where your owner signs; each item carries an evidence object, a version identifier, an approver and a date.
How is an AI audit trail built?
An AI audit trail is built in five steps, and you can stop after any of them: a free scoping call, a two-week evidence review, a four-week pilot linking one system’s records, production for further systems, then quarterly Managed Ops. Each stage closes on a signed record.
01 30 min · free
Scope We map the system, who is asking for evidence and by when, which tools hold its code, models, data, tests and approvals, and who owns it. A diagnostic quote follows the call.
02 2 weeks · credited
Diagnose Every evidence object located with its owner and identifier; each link between versions, data, tests and approvals marked present, partial or missing; gaps assigned to owners; the pilot priced in writing.
03 4 weeks · fixed price
Pilot One system’s trail built: a lineage record per release, test evidence and approvals attached to their versions, the change log opened, missing records requested, a weekly review, and your owner signs on the final day.
04 Per system · quoted after pilot
Production The next systems follow in the evidence review’s order, each with its own trail, plus retention and access rules per evidence object, a change procedure your teams follow and a handover session.
05 Quarterly · optional
Managed Ops A quarterly reconciliation: every release since the last review checked against its lineage record, tests and approvals, gaps listed with owners, retention applied, the change log signed. Cancel any quarter.
Who builds your AI audit trail?
A documentation lead who owns the evidence map and the link list, an engineer who reads repositories, model registries, pipelines and test tooling, and a reviewer who follows every link. All three work inside your repositories and document system, and your named owner signs each record before it is final.
Communication Weekly review calls, plus one Slack or Microsoft Teams channel we share
Delivery Your Git repositories, model registries, ticketing and document system
Quality assurance (QA) A second person checks every link; each version has a named approver
Retention A retention policy and access rule per evidence object
Boundary We create records; we do not run your pipelines or certify
Ownership Every record, schedule and template in your name
Which AI traceability starting point fits you?
Your starting point for AI traceability documentation depends on where your evidence stands; five questions show it. If nothing can be found, start with an evidence map. If records exist but do not link, start with one system’s audit trail. If releases are approved in chat, start with approval and change records. If a regulator is asking, start with a law-specific file. If there is no list of AI systems, start with AI governance documentation.
1. Is there a list of your AI systems in production?
2. Can you name the model and data version behind a given output?
3. Where do test and evaluation results live?
4. Are releases and changes approved by a named person?
5. Is anyone asking for the evidence right now?
Answer five questions to find your trail
One system’s audit trail as the pilot
Records that exist but do not cite each other are the normal starting point: the most exposed system gets a full trail (a lineage record per release, tests and approvals attached, a change log) in four weeks. You then decide whether production follows.
A first estimate; the evidence review confirms it.
How the verdict is decided
No list of systems → the governance inventory first
A regulator or a law asking → a law-specific file with the trail under it
Nothing findable → an evidence map first
Releases not approved by a named person → approval and change records first
Otherwise → one system’s audit trail
Why choose us for AI traceability documentation?
An AI traceability documentation company is judged on whether a stranger can follow the trail from decision to data, not on its tooling. Article 12 of the EU AI Act requires high-risk AI systems to allow the automatic recording of events (logs) over their lifetime, a duty the Act calls record-keeping; logs become evidence only when linked to versions, tests and approvals. We build the links, one system at a time, and the same trail can support the documented information an ISO/IEC 42001 AI management system asks for.
Which rules an AI audit trail helps you meet
| Rule or standard | What it requires | The record that answers it |
|---|---|---|
| EU AI Act, Article 12 | High-risk AI systems must allow the automatic recording of events (logs) over their lifetime. | Lineage and change records tie each log to a system, model and data version. |
| EU AI Act, Article 18 | Providers keep technical documentation and related records for 10 years after the system is placed on the market or put into service. | A retention schedule for each evidence object, kept in your own systems. |
| EU AI Act, Article 19 | Providers keep automatically generated logs for at least six months, unless other law sets a different period. | The retention schedule names each log store and its retention period. |
| NIST AI Risk Management Framework 1.0 | Four functions: Govern, Map, Measure and Manage. | Approval records support Govern, the evidence map supports Map, test evidence supports Measure and the change log supports Manage. |
| ISO/IEC 42001:2023 | Documented information for an AI management system. | The full trail, owned by you and signed by your named owner. |
We create the records these rules call for; we do not certify compliance or give legal advice.
Without a linked trail
Without a linked trail, test reports sit in five tools and none names the release it tested. Approvals live in chat threads, and nobody can name the data version behind the model in production. When an auditor asks who changed what, a dashboard of metrics cannot answer.
!!!!!
- Test reports in five tools, none naming the release they tested
- Approvals in chat threads that nobody can find under audit
- A model in production whose training data version nobody can name
- A dashboard that shows metrics but cannot show who changed what
With Eicra Soft Limited
After the pilot, every decision maps back to its release, model version and data version. Each test and approval is attached to the version it belongs to, gaps are listed with the owner who closes them, and a change log keeps the trail true. The illustrative report shows one credit-scoring model.
Pilot report · Credit-scoring model
Evidence objects4 of 4Links resolved22 of 22Gaps closed8Approvals recorded6VerdictTrail accepted
Illustrative example
- One lineage record per release, from decision back to data version
- Every test and approval attached to the version it belongs to
- Gaps listed by evidence object with the named owner who closes them
- A change log and retention schedule that keep the trail true
Is it safe to outsource AI traceability documentation?
Outsourcing AI traceability documentation is safe when access is read-only and your owner signs every record, because the risk is who can change a record and who sees code and data. As a Bangladesh-based company, our team works inside your systems under a non-disclosure agreement, reads records, never production data, and changes nothing without a ticket.
Which agreements are signed, and when?
Every agreement below is signed before we open any repository, dataset description, test report or approval record. That covers a mutual NDA, a data processing agreement for personal data in datasets or logs, and the transfer terms your jurisdiction requires. We never call your system audit-ready.
Non-disclosure agreement (NDA) — mutual, and signed before we open any repository, dataset description, test report or approval record.
Data processing agreement (DPA) — processor duties follow Article 28(3) of the General Data Protection Regulation (GDPR), or its national equivalent, for personal data in datasets, logs or examples.
International data transfers — no personal data leaves its jurisdiction until standard contractual clauses, or the local instrument, are signed.
Access — read access to repositories, model registries, pipelines, test tooling, ticketing and your document system; no write access to production, no credentials of ours.
Certifications — we list a certification only when we hold it, and we never certify your system or call it audit-ready.
Which ownership and rework terms apply?
You own every record from the first draft, and none of it sits with us. Only your named owner can make a record version final, and the trail stores each approval, date and version. A link that fails its acceptance list within thirty days is fixed free.
Your accounts From the first draft, every record, schedule and template lives in your repositories and document system; none sits with us.
Document ownership The contract gives you all intellectual property (IP) in the records, to hand to counsel, a customer or an assessor whenever you want.
Boundary We design the evidence structure and create records; we do not implement logging systems, run your pipelines, certify your system or give legal advice.
Approval Only your named owner can make a record version final, and the trail itself stores each approval, date and version.
Rework A link that fails its agreed acceptance list within thirty days of handover is fixed free; new systems or tools are quoted first.
What do you get before you pay for AI traceability documentation?
Before you pay for AI traceability documentation, you hold proof, not promises: a two-week evidence review with your own link-by-link gap list, a pilot trail your owner signs before production is quoted, and a free 30-minute scoping call. Client figures appear here only with each client’s consent.
2 weeks
For the evidence map and gap review, with every link between versions, data, tests and approvals marked.
4 weeks
To one AI system’s audit trail, built from your own records and signed by your owner.
30 days
After handover, any link that misses its agreed acceptance list is fixed at no cost.
Case studies: traceability results with client names are published only with consent. Ask on the scoping call for a reference from your sector.
What do buyers ask about AI traceability documentation?
Twelve questions buyers ask before they commission AI traceability documentation, each answered in its first sentence. They cover cost, what an audit trail is and contains, how links work, technical files, the steps after you enquire, tooling, ownership, data handling, location, switching providers and certification.
What does AI traceability documentation cost?
AI traceability documentation is priced per system, not per hour, starting with a free 30-minute scoping call, then a $1,500 two-week evidence review that ends in a written verdict (half credited to the pilot), a $4,000 fixed-price pilot for one system, and production from $6,000 per system. One AI system’s audit trail is then built, linked and signed by your owner, and further systems are quoted after the pilot.
What is AI traceability documentation?
AI traceability documentation is the set of linked records that lets a reader move from any AI decision back to the system version that produced it, the model and dataset versions inside it, the tests run on it, who approved its release and every change since. It is an audit trail across tools, kept as records your owners sign.
What should an AI audit trail contain?
An AI audit trail should contain seven items, each carrying an identifier the others cite: the system version and release date; the model version; the dataset versions with their sources; test results tied to the version they examined; approval records with names and dates; change records saying what changed and why; and the retention and access rule for each. Less is a folder, not a trail.
How does AI traceability link decisions?
AI traceability links decisions through identifiers. Every dataset version, model version and release carries one, and every test report, approval and change record cites the identifiers it concerns. A decision log entry names the release, the release names its model version, the model version names its training and evaluation datasets, so a reviewer walks from decision to data in three steps.
Is an audit trail a technical file?
No, an audit trail is not a technical file. A technical file is what one law requires for one system, and we draft those as EU AI Act documentation, not here; traceability documentation is the cross-system trail such a file draws its evidence from. You can hold a trail with no law in sight, but no file is credible without one, so the trail comes first.
What happens after I book a diagnostic?
A free 30-minute scoping call comes first, and every later step is yours to approve. Each step ends in a signed record, and if nothing is in scope, you stop after the review and keep it. The steps run in this order.
- We map the system, who is asking for evidence and which tools hold its records.
- A two-week evidence review marks each link present, partial or missing.
- A four-week pilot builds one system’s trail, signed by your owner.
- Further systems are quoted only after the pilot.
Do you install logging or MLOps tools?
No, Eicra Soft Limited does not install logging systems or machine learning operations (MLOps) tooling, and does not run your pipelines; we design the evidence structure and create the records. The trail is built from the repositories, model registries, ticketing tool and document system you already use, so no new platform is needed.
Who owns the records you create?
You own every record we create, from the first draft. The contract gives you all intellectual property in the records, and every record, schedule and template lives in your repositories and document system. None of it sits with us, so you can hand it to counsel, a customer or an assessor whenever you want.
How do you handle our data?
We handle your data read-only: we read records, never production data, and change nothing without a ticket. Access is read-only to repositories, model registries, pipelines, test tooling, ticketing and your document system, with no credentials of ours. A mutual NDA comes first, and a data processing agreement under Article 28(3) GDPR covers personal data.
Where is your team based?
The Eicra Soft Limited team is based in Dhaka, Bangladesh, and builds AI audit trails for international companies. Engineers work remotely inside your own systems under a non-disclosure agreement. No personal data leaves its jurisdiction until standard contractual clauses, or the local instrument, are signed, and production stays closed to write access.
Can we switch from our current provider?
Yes, you can switch from your current provider. The two-week evidence review locates the records you already hold, with their owners and identifiers, and marks each link present, partial or missing. The pilot is then priced from that gap list. Because every record lives in your own repositories and document system, nothing has to be handed back by a provider.
Will you certify our system as audit-ready?
No, we do not certify AI systems or call them audit-ready, and we list a certification only when we hold one. We also give no legal advice. What you receive is a linked trail your owner signs, which an auditor or assessor can then examine for themselves.
Start with a free 30-minute scoping call or the two-week evidence review.