Self-hosted AI governance tools for AI Act evidence, what they cover

Which self-hosted AI governance tools produce AI Act evidence?

When a customer, contract or regulator asks for AI Act evidence, the practical question is whether self-hosted open-source tools can supply it. They can. Tracing, evaluation, probing, guardrail and GRC tools produce logs and test records that support the record-keeping duty in Article 12 and the log retention duties in Article 19 (providers) and Article 26(6) (deployers). The organization still owns the controls, and an independent assessor or notified body decides conformity. The tools generate records; they do not generate a compliance finding. The answer depends on three things: the system's risk class, the organization's role as provider or deployer, and the license edition in use. A minimal-risk assistant may need little beyond basic traces and an inventory entry. A high-risk system needs logs that are kept under the organization's control for at least six months, unless other Union or national law requires longer, and that cover the operations the intended purpose calls for. Confirm the retention period against sector rules before you set a value, because the six-month figure is a floor, not a target. Langfuse's self-hosted audit logs, data retention policies, server-side masking and SCIM need an enterprise license key, so check whether those controls are in your edition before you promise them to a customer.

Test records come from a different set of tools. garak writes a JSONL report of every probe attempt and evaluation, plus a hit log of attempts that found a vulnerability, which is the kind of record a provider can file as evidence of adversarial testing. LLM Guard's input and output scanners can show what was screened, but the project was archived on July 9, 2026 and receives no security fixes. Treat it as a component you must maintain yourself or replace, and document that decision. CISO Assistant, licensed under AGPL-3.0-only, can hold the AI system inventory, control assessments and framework mappings, which is where most reviewers will start. Before you rely on any of these tools, run three checks: confirm the license terms that apply to your use (see each project's LICENSE file), confirm which capabilities sit behind an enterprise key, and map each record type to the specific article it supports. Ask your auditor or notified body which evidence they expect for your system, and keep the tool exports in a controlled, versioned location so the records can be produced later in their original form.

Which tool supports which AI Act duty?

Four tool categories produce different kinds of AI Act evidence, from runtime logs to test results to compliance records. Each card names the evidence type and what you must confirm against your own risk analysis before relying on it.

LLM tracing and logging

Langfuse records each request as a trace, covering LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. This is the closest match to the record-keeping duties in Articles 12, 19 and 26(6), which require logs under your control to be kept for at least six months unless other law says otherwise. Check that your retention settings meet that period, and confirm that audit logs and data retention policies are available in your edition, since the Langfuse documentation lists them as enterprise license features.

Evaluation and release gating

Langfuse scores production traces and runs experiments on datasets using LLM-as-a-judge evaluators and human annotation queues. It can also be wired into CI/CD to block a deployment when scores fall below a threshold. This supports evidence of testing and performance checks before changes reach users. Confirm that the judge model, the thresholds and the human reviewer criteria are documented and approved under your own quality management process, because an automated score alone rarely satisfies a reviewer.

Vulnerability probing reports

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Those files give you dated, repeatable records of robustness testing that you can attach to technical documentation and risk management records. Confirm which probes match the risks identified for your system, since a clean run covers only the probes that were executed.

Guardrails and framework tracking

LLM Guard provides input scanners such as PromptInjection, Anonymize, Secrets and Toxicity, and output scanners such as Sensitive, MaliciousURLs and FactualConsistency. CISO Assistant tracks audits and assessments against more than 200 frameworks with automatic mapping between them. Note that LLM Guard was archived on July 9, 2026 and receives no security fixes, so any guardrail you adopt needs a documented maintenance and replacement plan. Confirm with your compliance lead which framework mappings your auditors accept before relying on them.

What the logging duties in Article 12 and Article 19 ask for

Article 12 of the AI Act requires high-risk AI systems to technically allow for automatic recording of events, or logs, over the lifetime of the system. The purpose is traceability and monitoring: after something goes wrong or behaves unexpectedly, the organization should be able to reconstruct what the system did, when, and on which inputs. Article 19 makes providers keep the logs under their control, and Article 26(6) places a parallel duty on deployers. Both articles set a retention floor of at least six months, for a period appropriate to the intended purpose, unless other Union or national law requires longer. Confirm the current wording of these duties in the consolidated text of the Act before you set retention periods, since sector rules may be stricter.

A trace store, such as a self-hosted Langfuse deployment, is a source of logs, not a compliance answer by itself. Traces capture inputs, outputs, tool calls, token usage and timing, but the organization still decides which fields are captured, whether personal data is masked before storage, who holds the ADMIN or read roles, and how long traces are kept before deletion. Those decisions belong in a written logging standard that names the system, the log categories, the owner of each category and the retention period. Audit logs of administrative actions on the tool itself are a separate concern, and in Langfuse several of the controls that support them, including audit logs, project-level RBAC, data retention policies and server-side masking, require an enterprise license key. Confirm which of these you need before you choose an edition.

Before go-live, check three things with your team: that the logging standard matches the duties your role carries under Article 12 or Article 19, that a test export of logs can be produced and read by someone outside the engineering team, and that deletion jobs remove records on schedule without breaking the evidence trail for incidents still under review. If you use a partner to configure the stack, the retention and access decisions should be written into the statement of work and signed off by the organization, because the partner can prepare the logging but cannot decide what the organization must keep.

Which license and edition limits affect the evidence?

The MIT-licensed core of Langfuse covers the tracing and evaluation functions that produce most of the request-level evidence: traces of each operation with timing, inputs, outputs, token usage and metadata, plus evaluation of production traces and experiments on datasets. The features that govern who may see that evidence and how long it is kept sit outside the core. Self-hosted audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM provisioning need an enterprise license key.

Tracing and evaluation: The MIT core supports the record-keeping and monitoring evidence that teams often generate first.
Audit logs: Without the enterprise key, the self-hosted deployment does not provide the audit logs that show who changed what.
Retention and masking: Retention policies and server-side masking require the enterprise key, so personal data handling in traces depends on that licensing decision.
Access control: Project-level RBAC and SCIM need the enterprise key, which affects how access reviews are evidenced.
Protected prompt labels: Controls on prompt changes also sit behind the enterprise key.

Confirm with Langfuse which features your chosen edition includes before you design the logging and access controls around them.

How red teaming and probing fit the AI Act testing duties

The AI Act does not name a specific tool, and it does not require a particular type of red teaming in the provisions covered here. That means a probing run with garak is not a compliance finding. It is evidence that a test was performed against a defined system, and an assessor will judge whether that evidence supports the claim your organization makes about the system's robustness. Treat the output as one input to your risk management and testing records, not as a certificate that the system is safe or lawful.

garak writes two files you can keep as evidence. The JSONL report lists every attempt and its evaluation, so it shows what was tested and how the result was scored. The hit log lists only the attempts that found a vulnerability, which is the starting point for remediation. Before a run, record the exact model name, version or checkpoint, the system prompt and configuration, the guardrails in front of the model, the probe modules selected and the garak version. Store these with the run output in a versioned location. A probe run without that scoping cannot show which system the results describe, and results from an earlier version should not be reused as proof for a later release.

Every hit in the log should lead to a recorded decision: fix, accept with a documented rationale, or defer with an owner and date. Link each fix to the change that made it, then rerun the affected probes and keep both runs. Be clear about the limits. Probing covers certain failure modes, such as prompt injection, data leakage and jailbreaks, but it does not test bias, discrimination or effects on fundamental rights. Those risks need their own evidence, such as dataset analysis, subgroup performance testing and a documented impact assessment. Confirm with your legal or compliance team which obligations apply to your specific system before deciding what the probing evidence needs to cover.

How to turn tool output into an evidence file

This sequence turns raw traces, probe reports and guardrail results into a dated, versioned record that maps each artifact to the AI Act duty it supports. An assessor or market surveillance authority can then follow the chain from a system's risk class to the proof that its controls ran.

Define the AI system and its risk class
Start by writing down what the system does, who provides or deploys it, which model it calls, and where its output is used in the EU. Classify it against the AI Act's risk levels and note whether it is a provider or deployer use case, because that decides which logs and tests you must keep. The output is a signed-off system record with an owner, a risk class and a list of the duties it triggers. Do not treat the tool setup as the classification: the tool produces evidence, but the organization decides the risk class. Ask your legal or compliance lead to confirm the classification before engineering builds anything on top of it.
Decide which events the tracing layer captures
Configure the tracing layer, such as Langfuse, to record the events the system's duties need: model calls, retrieval steps, tool executions, inputs, outputs, token usage and version metadata. Set the retention period to match the log duties that apply to you, which for providers and deployers under the Act is at least six months unless other Union or national law requires longer. If you need audit logs, RBAC roles, data masking or retention policies in a self-hosted deployment, confirm with the vendor whether they need an enterprise license key. The output is a written logging configuration with a field list, retention setting and access roles, reviewed by the system owner.
Set evaluation thresholds and gate deployments
Define the quality metrics that matter for the system, such as factual consistency or task accuracy, and choose the evaluators, whether LLM-as-a-judge or human annotation queues. Set a minimum score for each metric and wire the evaluation into the CI/CD pipeline so that a build below the threshold does not deploy. The output is an evaluation specification with named metrics, thresholds, dataset versions and the pipeline rule that enforces them. Record who approved each threshold, since an assessor will ask who accepted the level of residual risk.
Run probing and guardrail tests on each release
For each release, run vulnerability probes such as garak against the model or system to test for prompt injection, data leakage, jailbreaks and hallucination, and run input and output scanners such as LLM Guard for the controls you have chosen. Check the vendor status of each scanner before you rely on it, because LLM Guard was archived on July 9, 2026 and receives no security fixes. Keep the garak JSONL report and hit log with the release identifier. The output is a dated test record for that build that lists what was tested, what failed and how each failure was resolved or accepted.
Store outputs with versions and dates
Move the traces, evaluation results, probe reports and test records into a store that the organization controls, with the model version, prompt version, dataset version and date attached to each item. Make sure the store is in your own infrastructure and that access is limited to the roles defined in step two. Test that you can retrieve a complete record for a past release. The output is an indexed evidence repository where any release can be reconstructed from its identifier without relying on the tool's interface.
Map each artifact to the duty it supports
Create a register that links every artifact to the article it supports, for example the record-keeping and log duties in Articles 12, 19 and 26, and to the control or risk entry in your governance system. CISO Assistant can hold this mapping and track assessments, or a controlled spreadsheet can do the same job for a smaller estate. Confirm with the assessor which mapping they expect before you finalize it. The output is a traceability register with one row per artifact, its owner, its review date and the duty it evidences.
Sign off the risk entry and review on change
Bring the evidence file to the accountable owner for a dated sign-off that records the risk class, the residual risks, the accepted thresholds and the open findings. Schedule a re-review whenever the model, prompt, dataset or risk class changes, and whenever a tool in the chain changes license or maintenance status. The output is a signed risk entry linked to the evidence bundle, plus a change log. Only the organization can accept the risk, and an independent assessor, not the tool vendor or implementation partner, decides whether the evidence is sufficient.

What makes these tools fail as evidence

A tool can run every test and still leave a compliance file with holes. The four risks below are the ones that most often turn self-hosted AI governance tooling into weak evidence, and each has a check you can run before an assessor asks.

Community edition for enterprise controls

Some controls you may need to evidence depend on features that sit behind an enterprise license. For Langfuse, self-hosted audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM all require an enterprise license key. Before you design a control around a feature, confirm with the vendor that your deployment will have that license key active and that the feature is enabled in your version.

Archived guardrail library in production

LLM Guard was archived on July 9, 2026. The project and its Hugging Face models are no longer developed or maintained, so they receive no security fixes. A guardrail that you cite as a control for prompt injection or data leakage is weak evidence if it is no longer maintained, and an assessor may ask what replaces it. Check the archive status of every scanner library in your stack and record a replacement plan with an owner and a review date.

Logs without retention or access rules

Article 12 requires high-risk AI systems to record events, and Articles 19 and 26(6) require providers and deployers to keep logs under their control for at least six months unless other Union or national law says otherwise. Traces that exist for a few weeks, or that anyone on the team can edit or delete, do not show that the logs were kept. Document the retention period, who can read and export the logs, and how deletion is recorded, then test that the setting works on a sample date.

Dashboards treated as proof

A screenshot of a trace view or a garak run summary shows that a tool ran, not that your AI system conforms to the Act. Conformity depends on the documented risk management, data governance, human oversight and quality management system around the tool. Keep the raw outputs, such as the garak JSONL report and hit log, with the test plan, the decisions taken on each finding, and the sign-off record. Ask your assessor early which artifacts they will request.

Questions buyers ask about AI governance tools and the AI Act

Do open-source AI governance tools satisfy the AI Act by themselves?

No. A tool can produce evidence, but it cannot make an organization compliant. The AI Act places duties on providers and deployers, and those duties attach to the organization's own processes, decisions and documentation. Tracing, evaluation, vulnerability probing and guardrail scanning generate records that support some duties, such as logging and testing. Risk management, human oversight, conformity assessment and the decision about whether a system is high-risk remain with the organization. Ask any implementation partner to show, duty by duty, which evidence comes from a tool and which comes from a person or a document.

Which AI governance tool should we start with?

Start with the question your evidence must answer first. If you need to show how a model or LLM application behaved in production, begin with tracing and evaluation, such as Langfuse, which records each request with its inputs, outputs, token usage and metadata. If you need to test a model before release, add a probing tool such as garak. If you need a register of AI systems, controls and assessments, look at a GRC tool such as CISO Assistant. Before choosing, check each candidate's maintenance status. LLM Guard was archived on July 9, 2026, so it receives no security fixes and needs a documented replacement or risk acceptance.

Do the MIT and Apache licenses allow internal use in our organization?

Generally, yes. The MIT license used by Langfuse and LLM Guard and the Apache-2.0 license used by garak permit use, modification and internal deployment without a fee, provided the license notice is kept. The AGPL-3.0-only license used by CISO Assistant has stronger obligations, mainly around distributing modified versions and offering source code to users who interact with them over a network. Read the LICENSE file in each repository and have your legal team confirm how the terms apply to your deployment and any changes your engineers make.

What does the enterprise license change for audit evidence?

It unlocks features that many auditors expect in a controlled logging environment. For Langfuse, the self-hosted features that need an enterprise license key include audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM. Without them, you must provide access control, retention, and masking through your own infrastructure and procedures, and document how that works. Confirm current edition terms with the vendor before you rely on a feature, because the feature list and the license terms can change.

How long must we keep AI system logs under the AI Act?

Article 19 for providers and Article 26(6) for deployers require logs under their control to be kept for a period appropriate to the intended purpose, of at least six months, unless other Union or national law provides otherwise. Article 12 sets the record-keeping duty for high-risk systems that the logs support. Retention is a design choice with recurring storage cost, so set it by purpose, then check sector rules that may require longer periods. Ask whether your retention policy, deletion process and access controls are documented, because an assessor will test them, not only the setting.

What does an implementation partner do with these tools?

An implementation partner plans, installs, configures, hardens, backs up and documents the tools inside your own infrastructure, then connects their output to your evidence register. DeployOpen works this way for self-hosted open-source platforms, within a fixed scope agreed in writing before work starts. The partner prepares systems and evidence. It does not decide your risk classification, issue a conformity assessment or certify compliance. Those belong to your organization, and, where the Act requires it, to a notified body or other independent assessor. Effort depends on the number of AI systems in scope, the state of existing logging, integration with identity and storage, and how many evidence processes must be written down. Request a quote built from that written scope.

What to confirm with vendors and your own environment before buying

Before you commit budget to any tool on this page, confirm the facts that will decide whether it fits. Start with the edition. Langfuse's audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM need an enterprise license key when self-hosted, so ask the vendor in writing which of the controls your evidence plan depends on are in the edition you will run. Confirm the license terms for your use case too. garak is Apache-2.0, LLM Guard is MIT and CISO Assistant is AGPL-3.0-only, and the AGPL obligations may matter if you modify and expose the software to users. Have counsel read the license file for each component rather than relying on a summary.

Next, check support status. LLM Guard was archived on July 9, 2026, so it receives no security fixes, and any scanner you put in front of a high-risk system needs a maintained path or a documented replacement. Ask each vendor or maintainer for its current release, its security disclosure process and its patch cadence, and record the answers in your AI system inventory. Then confirm where traces will live. Langfuse traces can contain prompts, outputs and personal data, so establish the region of storage, the backup location and which subprocessors can see the data, and make sure your own infrastructure matches the answer.

Two decisions sit with you, not the vendor. The first is retention. Article 19 and Article 26(6) set a floor of at least six months for logs under your control, unless other Union or national law provides otherwise, but the period you actually keep depends on your intended purpose and on sector rules, so set it through your own legal review. The second is whether any of these systems is high-risk at all, which depends on the Article 6(3) analysis of your use case. Also check the dates. The 2026 amendment moved the high-risk rules to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems, so confirm the current text in the consolidated Act before setting deadlines.

How DeployOpen deploys and documents self-hosted AI governance tools

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AI Act evidence, we scope the tracing, evaluation, testing, guardrail and GRC tools to the logging and testing duties your organization must meet, then hand over configured systems and written records your assessors can review.

How we scope

We map each AI system to the logging, testing and record duties that apply to your provider or deployer role.
We confirm which tool editions, licenses and feature gates your required audit logs and access controls depend on.
We agree the scope, deliverables and timelines in writing before any work starts, as most engagements are fixed-scope.

How we build

We install and configure tracing, evaluation, probing and guardrail tools in your infrastructure, under your control.
We set log retention, access roles and data masking to match the retention period your legal advisers confirm.
We test the integrations, including CI/CD gates and scanner configurations, and record the results as evidence.

How we hand over

We document architecture, configuration, runbooks and the evidence each tool produces, mapped to the relevant article.
We train your engineers and compliance staff to operate the tools and retrieve logs, reports and hit logs.
We state clearly which records remain your responsibility, and that independent auditors or notified bodies issue any formal assessment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We monitor vendor release and maintenance status, including any project that stops receiving security fixes.
We update configurations and documentation when the AI Act timeline, your AI systems or your tool versions change.

Self-hosted AI governance tools for AI Act evidence