EU AI Act evidence

An evidence pack is a ZIP of the records Tawa Guard kept for one app over one period: every request it scanned, the configuration in force for each one, the decisions your reviewers recorded, and a PDF that sets those records beside seven articles of the EU AI Act. A manifest lists every file with its SHA-256 hash. On the Team plan and above the manifest is signed by Tawa Guard, so a reader can check that no file changed after the pack was produced.

The pack is for teams that keep records under the EU AI Act, or follow its practices voluntarily, and for the legal, risk and procurement reviewers they share those records with.

Every pack names the text it was written against:

The pack contains metadata and verdicts only. It contains no scanned text. Preview scans run from the dashboard are left out of every figure and every file.

Plans

A request for a period longer than the plan allows is refused with a message that names the plan, for example "Periods up to 92 days are available on Starter. Longer periods need the Business plan." The period is never shortened to fit.

Generate a pack

Packs are generated per app, from the app's Evidence page in the dashboard. Generating, listing, downloading and verifying packs needs permission to view the workspace audit log, which owners and admins have by default. A full pack holds the workspace audit log extract, every policy rule in force and the roles of reviewers.

1. Open the app and select Evidence.
2. Under Period, choose one of the options below.
3. Select Generate pack. Generation can take up to 5 minutes. The pack appears in the list on the same page as Generating, then Ready.
4. Select Download to get the ZIP.

All dates and times are UTC. Each pack has a period key: YYYY-MM for a month, YYYY-MM-DD_YYYY-MM-DD for a custom range (the second date is the day after the last day, because the end is exclusive), and rolling_<start>_<end> for Last month (up to now), with both instants to the second. The ZIP is named tawaguard-evidence-<workspace>-<app>-<period key>.zip.

Generating a pack again for the same period creates a new pack. The earlier one is kept and both are listed. Packs are stored until the workspace is deleted. Generating and downloading a pack are each recorded in the workspace audit log.

Monthly scheduled pack

On Business and Enterprise, Tawa Guard generates a pack for every app that is not archived at the start of each month. It covers the previous calendar month in full. The workspace's owners and admins receive an email when it is ready. The scheduled pack is separate from Last month (up to now), which covers a rolling month and is generated only when you ask for it.

What is in the pack

Every file that lists requests names each one by its job ID: the job_id column, or jobId in incidents.json. Join files on that ID, not on a time stamp, because time stamps are not written to the same precision in every file.

Failed scans are included in requests.csv and requests.jsonl with an empty engine_action, and are counted separately as failed scans.

manifest.json is minified JSON with sorted keys, so the same manifest always has the same bytes. To read it:

jq . manifest.json

Data completeness

The PDF, README.txt and manifest.json each report what the period's data cannot show:

For a Last month (up to now) pack on Team and above, the pack also says that spike alerts are listed for every UTC day the period touches, so an alert for the first day may count activity from before the period starts.

A pack that includes the audit log extract keeps its copy after the entries it holds are purged from Tawa Guard. Each monthly scheduled pack therefore keeps that month's audit log beyond the 400 days.

Verify a pack

In the dashboard

Verify in the packs list checks the copy of the pack that Tawa Guard stores:

• manifest.json is compared with the hash recorded when the pack was made.
• Each file the manifest lists is read, and its SHA-256 hash and size are compared with the manifest. A file that fails is named with the reason: missing from storage, contents that do not match, or a size that does not match.
• On signed packs, manifest.sig is checked with the current signing key. A pack signed with a previous key cannot be checked there. That does not mean the pack has changed: check a downloaded copy against the key its manifest names.

To check a copy you downloaded, use the steps below. They are the steps README.txt gives inside the ZIP.

A downloaded copy

Run these commands from the folder you unzipped the pack into. They need OpenSSL 3 or later (openssl version shows yours) and jq. On macOS, use shasum -a 256 wherever these steps say sha256sum.

cat > public.pem <<'EOF'
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAHvdCrpAf/l09L/HOgzISXDqudlr63T1MehFwep7YEJc=
-----END PUBLIC KEY-----
EOF

openssl pkey -pubin -in public.pem -outform DER | sha256sum

openssl base64 -d -in manifest.sig -out manifest.sig.bin

openssl pkeyutl -verify -pubin -inkey public.pem -rawin -in manifest.json -sigfile manifest.sig.bin

jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json | sha256sum -c

If the key's fingerprint matches the one on this page, a valid signature on manifest.json together with every file passing the last check shows the files are as Tawa Guard produced them.

README.txt, manifest.json and manifest.sig are not listed in manifest.json. manifest.json is covered by manifest.sig instead. README.txt is a guide only and no check covers it. Any other file in the folder that the manifest does not list is not part of the pack as produced.

README.txt prints the fingerprint of the key that signed the pack, and may print the key itself. A key carried inside the pack cannot vouch for the pack, so compare the fingerprint with the one on this page.

A Starter pack has no manifest.sig, so run only the last check. Without a signature it shows that the files match manifest.json, but not who produced manifest.json.

The audit log extract

Each audit entry carries a hash that links it to the entry before it. The chain runs across all Tawa Guard workspaces and each hash is keyed with a Tawa Guard secret, so the chain cannot be recomputed from the extract in a pack. Tawa Guard checks the chain when it generates the pack and records the result in audit-chain-head.json and in the manifest: intact up to a given entry, a break, or unknown when the check could not run. What protects audit-log.jsonl in the pack is the manifest, like every other file.

Signing key

Signed packs use Ed25519. The fingerprint is the lowercase hex SHA-256 of the public key in DER (SPKI) form. Each signed manifest names the fingerprint of the key that signed it in signing.publicKeyFingerprint.

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAHvdCrpAf/l09L/HOgzISXDqudlr63T1MehFwep7YEJc=
-----END PUBLIC KEY-----

Changes to the signing key are announced on this page. A pack verifies against the key whose fingerprint its own manifest.json names, so a pack signed before a key change still verifies against the key it was signed with.

Oversight records

A member of your team can record a decision on a completed request, on the request's detail page or for several selected requests at once from the jobs list. The decisions are confirmed block, confirmed allow, false positive, false negative and escalated.

Each decision records the reviewer's role, the time and an optional note of up to 2,000 characters. A decision is never edited: a changed mind is a new decision that replaces the earlier one, and requests.csv shows the latest. The pack names reviewers by role, never by person, and oversight.csv includes the note. Recording decisions needs the record oversight permission, which owners, admins, editors and members have by default and viewers do not.

Reviewing requests is optional, and no decision is expected on any given request. Whether or not anyone reviewed them, the pack counts the requests Tawa Guard blocked and flagged, and each row in requests.csv shows what was decided and why: the verdict, the risk, the attack class and the matched policy rules.

Articles mapped

Tawa Guard scans the prompts, retrieved chunks, tool calls and tool outputs that your application sends to it. For each request it records a verdict, a risk score and the settings in force at the time. This pack reports those records for one app over one period and sets them beside seven articles of the Regulation. It reports what Tawa Guard recorded. It does not assess your AI system, or Tawa Guard, against the Regulation.

Whether your AI system is high-risk, which obligations apply to you, and from when, are questions for you and your legal counsel.

Each section below follows the same order: what the article asks, what Tawa Guard records that bears on it, the figures for the period, what the section does not cover, and the file in the pack that holds the evidence. Where a figure is counted from a file in the pack, the table names that file and the column, so you can count it again yourself. In a Starter pack, a figure counted from a file the pack does not hold reads "Included from Team". See The decision for the verdicts and actions Tawa Guard returns.

Article 15(5): Cybersecurity and resilience to adversarial input

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 15(5) asks that a high-risk AI system is resilient against attempts by unauthorised third parties to alter its use, outputs or performance by exploiting system vulnerabilities. It lists attacks that technical measures should prevent, detect, respond to, resolve and control where appropriate. One of these is inputs designed to cause the AI model to make a mistake, which the Article calls adversarial examples or model evasion. These are requirements for the high-risk AI system itself.

The Regulation does not name prompt injection. Tawa Guard's records are offered as evidence toward two of the Article's wordings: attempts by unauthorised third parties to alter use, outputs or performance, and inputs designed to cause the model to make a mistake.

What Tawa Guard does

Tawa Guard scans each prompt, retrieved chunk, tool call and tool output that your application sends to it. For each one it records a verdict, a risk score, the content shape and, where it detects one, the class of attack.

For each request Tawa Guard also records the policy version, the profile, the detection settings and the model bundle that were in force when it made the decision. A decision can therefore be explained later from the settings that produced it, even after those settings have changed. The policy versions in force or promoted during the period are listed in policy-versions.json.

Your application decides what to do with each verdict. The figures below count the action Tawa Guard returned to your application.

The shadow_mode column marks requests scanned while shadow mode was on. In shadow mode Tawa Guard records what it would have done without blocking the request, so figures for a period with shadow mode on should be read with that in mind.

Figures

What this does not cover

Tawa Guard scans the inputs and outputs your application sends to it. It does not cover the other attacks Article 15(5) lists: data poisoning, model poisoning, confidentiality attacks on the model, or flaws in the model itself. It does not cover requests your application does not send to Tawa Guard, or what your application does after it receives a verdict.

Evidence file: requests.csv

Article 12: Record-keeping

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 12 asks that a high-risk AI system technically allows events to be recorded automatically in logs over its lifetime. The logs should help identify situations that may present a risk, support post-market monitoring under Article 72, and support the monitoring of the system's operation.

What Tawa Guard does

Tawa Guard writes a record automatically for every request it scans. The record holds the time stamp, the app, the ID of the API key used, the content shape, the verdict, the risk score and confidence, any attack class and matched policy rules, and the configuration in force: the detection settings, the profile, the model bundle, and the policy version when the app has a policy. It holds no scanned text. requests.jsonl and requests.csv carry one row per request with the same columns. Not every row carries every value. The policy version is empty for a request from an app with no policy. The detection settings and profile are empty for requests from an app that had no saved detection settings at the time. Requests recorded before Tawa Guard began recording these values also have no policy version. The pack's data completeness box gives the number of requests without these values and the date of the first request in the period that carries them.

Changes to settings, API keys and apps, and each oversight decision, are written to an audit log. Each audit entry carries a hash that links it to the entry before it, so a gap or an edit in the chain can be detected by Tawa Guard. Tawa Guard checks the chain when it generates the pack and records the result in audit-chain-head.json. The chain is shared across all Tawa Guard customers and each hash is keyed with a Tawa Guard secret, so you cannot recompute it from your own extract. You can check that the extract has not changed since the pack was produced, using the manifest. The audit-log extract is included in packs on the Team plan and above.

Figures

What this does not cover

These logs cover what crosses the Tawa Guard boundary. They do not cover the logs of your own AI system, your application, your model provider or any other component outside Tawa Guard.

Evidence file: requests.jsonl

Article 26(5): Deployer monitoring of operation

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 26(5) asks a deployer of a high-risk AI system to monitor its operation on the basis of the instructions for use. Where the deployer has reason to consider that use may present a risk within the meaning of Article 79(1), it informs the provider or distributor and the relevant market surveillance authority and suspends use. Where it identifies a serious incident, it informs the provider first and then the others the Article names.

For a financial institution subject to internal governance rules under Union financial services law, the Regulation treats this monitoring duty as fulfilled through those governance rules. Your legal counsel can confirm whether that applies to you.

What Tawa Guard does

The per-request log described under Article 12 lets your team see, request by request, what Tawa Guard decided.

When Tawa Guard flags a request for review, a member of your team can record a decision on it: confirmed block, confirmed allow, false positive, false negative or escalated. Tawa Guard records the decision, the reviewer's role, the time and an optional note. Reviewing requests is optional and no decision is expected on any given request. oversight.csv lists the decisions recorded in the period. The latest decision on each request also appears in requests.csv.

If you turn on spike alerts, Tawa Guard raises an alert when the number of blocked or flagged requests on one day rises above a threshold you set against the average of the days before it. It records when each alert was raised and when it was acknowledged. incidents.json lists the alerts raised in the period.

Figures

What this does not cover

Tawa Guard records what your team decided inside the dashboard. It does not record whether you informed your provider, a distributor or a market surveillance authority, or whether you suspended use of your system. It does not cover monitoring of anything outside Tawa Guard.

Evidence file: oversight.csv

Article 26(6): Deployer log retention

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 26(6) asks a deployer of a high-risk AI system to keep the logs the system generates automatically, to the extent they are under its control, for a period suited to the system's intended purpose and of at least six months, unless other Union or national law, data protection law in particular, provides otherwise.

For a financial institution subject to internal governance rules under Union financial services law, the Regulation asks it to keep these logs as part of the documentation it keeps under that law. Your legal counsel can confirm whether that applies to you.

What Tawa Guard does

Tawa Guard keeps job metadata, which is the per-request record in requests.csv and requests.jsonl, for the lifetime of your workspace. If you delete the workspace, the job metadata is deleted with it.

Tawa Guard keeps audit log entries for 400 days. If the period of a pack reaches back further than that, the pack says so in its data completeness box, with the number of days affected.

Tawa Guard keeps the text it scanned only if you turn on prompt retention. Stored text is deleted at the end of its retention window, which you choose up to a ceiling set by your plan. The payload_deleted_at column shows when stored text for a request was deleted. The pack itself never contains scanned text.

Evidence packs are kept until the workspace is deleted. A pack that includes the audit-log extract keeps its copy after the entries it holds are purged from Tawa Guard.

Figures

What this does not cover

This covers only what Tawa Guard keeps. It does not cover the retention of your own system's logs, your application's logs, or copies of this pack that you store elsewhere. Whether these retention periods suit your system's intended purpose is for you to decide.

Evidence file: requests.csv

Article 72: Post-market monitoring

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 72 asks the provider of a high-risk AI system to set up and document a post-market monitoring system. The provider collects, documents and analyses data on the system's performance throughout its lifetime, which may come from deployers or from other sources. This is a duty of the provider. If you deploy a system that someone else provides, the records below are data you could share with that provider.

What Tawa Guard does

Each pack reports the period's counts in the same way, so packs for successive periods can be compared to see how the volume and type of attacks and the outcomes of review change over time.

When a reviewer records a false positive or a false negative on a flagged request, Tawa Guard counts it as a report on how detection performed. These reports are in oversight.csv.

Tawa Guard records every policy version promoted and every detection settings version in force, with its date, and the model bundle used for each request. A change in the figures can therefore be set against the changes in settings or detection that came before it.

Figures

What this does not cover

This pack is data that a post-market monitoring system can use. It is not the monitoring plan, and it does not cover the analysis or the actions a provider takes on that data.

Evidence file: requests.csv

Article 73: Reporting of serious incidents

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 73 asks the provider of a high-risk AI system to report a serious incident to the market surveillance authority. The report is due not later than 15 days after the provider becomes aware of the incident. In the case of a widespread infringement or a serious incident as defined in Article 3, point (49)(b), it is due not later than 2 days after the provider becomes aware of it. Where a person has died, it is due not later than 10 days after. An initial report may be incomplete and followed by a complete one. The provider has the primary duty. The Article also refers to deployers where it applies to them, and Article 26(5) asks a deployer that identifies a serious incident to inform the provider first.

What Tawa Guard does

Tawa Guard keeps the records that can help you reconstruct what happened around an incident. Each hard block is listed in incidents.json with its time stamp, risk score and attack class. Each spike alert is listed with when it was raised and when it was acknowledged. Every request behind these entries is in requests.csv, with its time stamp to the second.

Figures

What this does not cover

Tawa Guard does not decide whether an event is a serious incident under the Regulation, and it does not file or draft any report. Tawa Guard does not label a hard block or a spike alert as a serious incident. Whether an event is one is for you and your provider to decide. The time limits run from when you or your provider become aware of an incident, and nothing in this pack sets that time.

Evidence file: incidents.json

Article 95: Voluntary codes of conduct

What the article asks

This section is intended to assist your own compliance work. It is not legal advice, it is not legally binding, and it does not establish conformity with the Regulation. Have it reviewed by your own legal counsel.

Article 95 encourages voluntary codes of conduct under which operators of AI systems that are not high-risk apply some or all of the requirements for high-risk systems.

What Tawa Guard does

If your AI system is not high-risk, the records in this pack can support a voluntary practice of that kind. The pack sets out what Tawa Guard recorded in the period: the verdict on each request, the settings in force, the decisions your reviewers recorded and the alerts raised. The earlier sections show which article each record bears on.

Figures

What this does not cover

This pack does not decide whether your system is high-risk, and it is not a code of conduct. Drawing up or signing up to a code of conduct is your own decision.

Evidence file: manifest.json

What the pack does not cover

This pack covers what Tawa Guard records at its boundary. Much of what the Regulation asks of a high-risk AI system is your own work or your provider's, and Tawa Guard does not evidence it. In particular, this pack does not cover:

• the risk management system that Article 9 asks for
• the data and data governance that Article 10 asks for, including how a model was trained
• the technical documentation that Article 11 asks for
• the transparency and information for deployers that Article 13 asks for
• the design of the human oversight measures that Article 14 asks for
• whether your AI system is high-risk, and which obligations apply to you

Tawa Guard records the oversight decisions your team makes on flagged requests. It does not evidence how oversight of your system is designed or staffed.

Tawa Guard does not see requests your application does not send to it, and it does not see what your application does with a verdict. The pack reports what Tawa Guard recorded and nothing beyond it.