AI System Cards: What Goes Inside, Which Regulators Expect Them, and Where the Operational Evidence Comes From

An AI system card documents an AI system as deployed. It extends the model-card concept that Margaret Mitchell and co-authors introduced in 2018 from a model artifact to a deployed-system artifact. Where a model card describes the model's training data, intended uses, and benchmark performance, a system card describes the operating environment around the model: the policies in effect, the human oversight mechanisms, the audit-trail format, the responsible roles inside the deployer's organization, and the decommissioning plan. Regulators expect system cards under EU AI Act Article 11 technical documentation requirements, ISO 42001 Clause 7.5 documented information requirements, NIST AI RMF MAP function activities, and Fannie Mae LL-2026-04 Pillar 1 inventory obligations.

The system card is a static document. The audit-evidence layer that feeds it is operational. A system card written without operational evidence is a self-attestation that the regulator will discount. A system card backed by per-decision audit records is an artifact that survives a serious-incident review.

I want to walk through the eight fields a system card needs, the regulators that expect them, and how the operational evidence at the AI request layer feeds the card.

The eight fields a system card has to contain

The fields below are the union of what EU AI Act Article 11, ISO 42001 Clause 7.5, NIST AI RMF MAP, and Fannie Mae LL-2026-04 Pillar 1 each require. A system card that contains all eight fields satisfies the documentation requirements of all four frameworks at once.

Field 1: Intended use and deployment context

The intended-use field describes what the system does, the population it serves, the geography of operation, and the decisions it informs. The field has to be precise enough that a regulator can determine whether the system falls inside a risk-classified use case (e.g., EU AI Act Annex III). Vague intended-use statements ("supports business operations") fail the precision test. Precise statements ("evaluates job-application screening decisions for candidates applying to engineering roles in the EU and UK markets") pass it.

Field 2: Operating environment and architecture

The operating-environment field describes the technical stack the system runs on: the model provider, the gateway layer, the identity provider, the policy engine, the audit log destination, and the data classification tooling. A diagram is helpful. The architecture has to be specific enough that a regulator can trace a request from the user's input through the model and back to the decision communicated to the data subject.

Field 3: Human oversight mechanisms

The human-oversight field describes the points in the workflow where humans can intervene, the roles those humans hold, the decisions they can make, and the records they produce. For an EU AI Act high-risk system, the oversight design has to satisfy Article 14. For a Fannie Mae system, the oversight design has to satisfy LL-2026-04 Pillar 5. For a GDPR Article 22 workflow, the human review has to satisfy the meaningful-review test.

Field 4: Policies and rules in effect

The policies field describes the access-control policies, classification policies, routing policies, and disclosure policies that govern the system. The field has to capture the policies as code or as concrete rule sets, not as aspirational statements. "Sensitive data is protected" is not a policy. "PHI categories listed in HIPAA 164.514(b)(2)(A) are redacted from prompts before transmission to the model provider, enforced by the gateway, with the redaction recorded in the audit log" is a policy.

Field 5: Data inputs, outputs, and classifications

The data field describes what data the system processes: input categories, sensitivity classifications, retention periods, cross-border movement, and disclosure to third parties (including the model provider). For HIPAA-regulated systems, the field has to support the Business Associate Agreement boundary analysis. For DORA-regulated systems, the field has to support the ICT register's location-of-processing requirement.

Field 6: Audit-trail format and retention

The audit-trail field describes the format of the per-decision audit record, the fields captured, the retention period, the storage location, the access controls on the records, and the tamper protection. The format description should reference the EU AI Act Article 19 minimum fields, ISO 42001 Clause 9.1 monitoring inputs, NIST AI RMF MEASURE.2.7 evidence requirements, and any sector-specific obligations (HIPAA, DORA, SR 11-7).

Field 7: Responsible roles and accountability

The roles field identifies the human roles inside the deployer's organization that are accountable for the system: the business owner, the technical owner, the data protection officer, the model risk officer, and the incident response lead. The names of individuals can change; the field describes the roles and the reporting structure. For EU AI Act Article 26, the field also has to identify who notifies the competent authority if a serious incident occurs.

Field 8: Decommissioning plan

The decommissioning field describes the conditions under which the system is taken out of service, the steps to do so, the data-disposal procedure, the record-retention obligations that outlast the system, and the customer-notification plan. Most deployment programs skip this field. EU AI Act Article 26(7) explicitly requires it for high-risk systems.

Which regulators expect a system card

EU AI Act Article 11 requires technical documentation for high-risk AI systems. Annex IV lists the required content. The Annex IV list maps almost exactly onto the eight fields above, with additional emphasis on the conformity assessment process and the post-market monitoring plan.

ISO 42001 Clause 7.5 requires documented information for the AI Management System. The standard does not prescribe a specific format, but the Annex A controls cross-reference the eight fields above. An ISO 42001 certification audit will ask for the documentation that proves each Annex A control is operational.

NIST AI RMF's MAP function activities require the deploying organization to map the AI system in context: its scope, its intended use, the actors involved, the impacts, and the dependencies. The MAP outputs are the system-card content under a different name.

Fannie Mae LL-2026-04 Pillar 1 requires sellers and servicers to maintain an inventory of AI and ML systems with sufficient detail to support the other four pillars (data quality, model governance, monitoring, and oversight). The Pillar 1 inventory is a system card at scale.

Where the operational evidence comes from

The system card is documentation. The audit evidence that backs the documentation is operational. Eight fields connect:

• Intended use: feeds from the request patterns observed in the audit log over time. The system card claims the system serves population X for decisions of type Y; the audit log shows the actual population and decision types. A mismatch is a finding.
• Architecture: feeds from the configuration as code. The gateway configuration, the identity provider configuration, the policy engine configuration, and the audit log configuration are all reviewable artifacts.
• Human oversight: feeds from the audit log entries that record the human reviewer's identity and decision. A system card that claims human review for decision type Y has to match an audit log that shows the reviewer for each such decision.
• Policies in effect: feeds from the policy decision point's records. Each per-decision audit record captures the policy version and the routing rule applied at the moment of decision. The system card claims policy X is enforced; the audit records prove it.
• Data classifications: feeds from the classification engine's records. The audit log captures the classification assigned to each input, and the policy that depended on the classification.
• Audit-trail format: feeds from the audit log itself. The format the system card describes has to match the format the log writes.
• Responsible roles: feeds from the IAM system's role assignments. The roles in the system card have to map to actual identities in the IAM system.
• Decommissioning plan: feeds from the retention configuration. The retention periods in the system card have to match the configured retention in the audit log store.

DeepInspect

The per-decision audit log that DeepInspect writes is the operational evidence that backs the AI system card. Every request through the gateway produces a record with identity (natural person, application, agent), classification of the input data, the policy version and routing rule applied, the model called, and the outcome returned. The records are written outside the application, so the application cannot alter them. The records carry the natural-person identity that standard application logging routinely misses.

When a regulator asks for the system card and the evidence behind it, the system card describes the design and the audit log proves the design is operational. The two artifacts together satisfy EU AI Act Article 11 and Article 12, ISO 42001 Clause 7.5 and Clause 9.1, NIST AI RMF MAP and MEASURE, and Fannie Mae LL-2026-04 Pillar 1 and Pillar 4. The same evidence layer satisfies multiple regimes at once.

If you are building system cards for your AI deployments and the evidence layer has gaps, book a demo today.