TISAX AI Audit Evidence: Build the Sample Around Actual Model Traffic

A TISAX assessor asks for objective evidence that a process achieves its purpose. The current VDA Information Security Assessment workbook, version six point zero point three and the basis for TISAX assessments opened under ISA 6, describes that evidence as work products and interview statements. Its target maturity level is 3, Established, across the information security control questions. That means a written AI usage policy needs a sustained operating record behind it.

For AI services, the strongest record starts with one outbound model request. It names the originating identity, information classification, approved destination, policy version and outcome. I want to build the assessor package around that event, then connect it to the risk, supplier and governance records that sit elsewhere.

Assessment scope and current ISA baseline

TISAX is an assessment and exchange mechanism governed by the ENX Association. Approved audit providers assess participants against the VDA ISA catalogue, and participants control the release of standardized result summaries through the ENX Portal. Customer and supplier relationships usually create the practical requirement. TISAX itself remains an industry mechanism rather than a statute.

The scope record comes first because an assessor reads every artifact against it. Name the legal entity, locations, processes, supporting assets, cloud tenants and external IT services involved in the AI use case. Include the gateway, identity provider, model endpoint, retrieval store and log repository. A diagram with the model call leaving the marked assessment boundary at 14:06 gives the reviewer a concrete route to test.

ENX has also published ISA2027 as the upcoming catalogue. It applies to assessments ordered in 2027. For an assessment opened in August 2026, use the current ISA 6 workbook as the operative baseline and track the 2027 transition as change work.

External-service approval and risk file

The ISA control for evaluated and approved external IT services calls for an explicit assessment, alignment with the protection need, documented approval and periodic verification that only approved services are used. The risk-management control adds documented information security risks, a named risk owner, treatment measures and reassessment after relevant change.

The evidence package should join those requirements in one AI service file. Keep the approved provider, model host, intended use, information classes, processing location, service owner, risk owner and approval date. Add the risk assessment, treatment plan and review history. Then reconcile the approved host list against observed HTTP model traffic for a defined sample period.

A procurement spreadsheet says which service the company intended to use. A route record says where production data went. My view is blunt: an assessor should weight the route record more heavily when those two artifacts disagree.

Identity and authorization sample

The secure user-access control covers access to IT services and systems. For an AI request, the assessor needs the principal behind the application credential. A shared API key identifies a workload while leaving the employee or agent that initiated the action unresolved.

Build a sample with at least five records: a permitted request, a denial, a redaction, a request after a role change and an evaluator failure. Each record should carry a stable event identifier, authenticated principal, asserted role, workload identity, model destination, information class, policy version, decision and timestamp. Link the principal to the identity provider record and the role to its approval.

This is also where delegated authority becomes visible. If a purchasing agent may summarize an approved supplier file through one model route, its record should show that narrow permission. A request carrying prototype material to a general-purpose endpoint should produce a denial under the same identity chain.

Event-log integrity and reconstruction

The ISA event-logging control asks organizations to determine log requirements, assess systems for logging, consider monitoring options in external IT services and check logs for rule violations. It also calls for protection against alteration and an escalation procedure for relevant events.

An AI evidence package needs the schema, retention rule, access list, integrity mechanism and one exported sample. The record writer should sit outside the application making the model call. Add a signature or chained integrity value, synchronized timestamp and policy digest. Then run a reconstruction test: select event ai-2026-08-11-1406, retrieve the identity approval, policy version, classification result, destination rule and final decision without asking the application team to rebuild the story manually.

The useful visual is a single red denial row beside four green permits on the assessor's screen. That row proves the control evaluated content and made an independent decision.

Supplier and shared-responsibility evidence

The ISA supplier-assurance control addresses information security among contractors and cooperation partners. It expects risk assessment, contractual treatment, review of service reports and evidence appropriate to the protection need. The shared-responsibility control allocates information security work between the organization and external IT service providers.

For a hosted model, retain the supplier assessment, contract requirements, service configuration, data-use terms, incident contacts and responsibility matrix. Bind those documents to the observed endpoint and model route. A supplier attestation supports the provider side of the file. The deploying organization still needs evidence for its own identity propagation, information classification, approval and monitoring.

Review the matrix against one failure scenario. If the provider changes a processing feature, procurement owns the contract review, platform engineering owns route configuration, security owns the risk treatment, and the business owner decides whether the use remains approved. The record should show each handoff.

Sampling across maturity levels

The TISAX Participant Handbook explains the assessment process, scope, objectives, maturity model and result exchange. The current ISA workbook defines maturity level 1 as a performed process with some evidence, level 2 as a managed process with documentation and implementation evidence, and level 3 as an established standard process integrated with related processes and used sustainably.

A single screenshot can support performance. It gives weak support for management or sustained use. Build the sample across time: one week before a policy change, the change approval itself, one week after deployment, and the latest quarterly review. Include exceptions, failed evaluations and remediated findings. Preserve who selected the sample and the query used to produce it.

For each selected request, the assessor should be able to move through the event record, identity, approved service, risk treatment and supplier responsibility without finding a blank join key.

Evidence outside the HTTP boundary

An HTTP policy gateway covers authenticated traffic sent to HTTP-based LLM endpoints. It can classify the request, apply destination and role policy, inspect the response, refuse traffic and write an independent decision record. That boundary supplies evidence for actual model use.

TISAX examines the wider ISMS inside the registered assessment scope. Workforce screening and training, physical security, endpoint configuration, software patching, cloud IAM administration, supplier contracting, business continuity and management review sit outside the HTTP request path. Model quality testing and the truth of generated output also need separate controls. Keep those artifacts in the package under named owners rather than stretching a traffic record into proof it was never designed to provide.

The TISAX AI compliance checklist turns this package into owner-based completion tests. The TISAX AI controls mapping shows the contribution and boundary for each control family.

DeepInspect

DeepInspect supplies the independent runtime evidence in this package. It sits inline between authenticated users or agents and HTTP-based LLM endpoints. Each request is evaluated against identity, role, information classification, destination and policy before the model receives it, with a fail-closed default and a signed, tamper-evident decision record outside the calling application's write path.

Those records let an assessor reconcile approved services against observed use, test role and destination decisions, inspect denied traffic, retrieve the policy in force and bound an incident sample. Supplier agreements, IAM administration, workforce controls, cloud configuration and the rest of the ISMS stay with their named owners. Book a technical deep dive at deepinspect.ai.