Petar Tsankov says organizations need a centralized process to inventory AI applications, classify their risks, and demonstrate that important systems are safe and compliant.
2
LatticeFlow AI's open-source Comply framework translates EU AI Act principles into technical requirements, evaluation methods, benchmarks, and scores for language models.
3
Compliance benchmarks need to become dynamic and more complete, since static tests can be overfit and some areas, such as copyright and explainability, remain difficult to measure.
Summary
Petar Tsankov describes how AI governance has shifted from abstract fears about AI to the practical work of managing large numbers of deployed applications. Organizations need to know which models they have, what they do, which ones affect the business, and which risks require attention. He explains Comply, an open-source LatticeFlow AI project that maps EU AI Act requirements to technical requirements and evaluation methods for language models. The framework produces scores for areas such as toxicity, robustness, fairness, prompt leakage, and cybersecurity. Tsankov is clear about its limits. Copyright checks are incomplete, explainability is hard to define technically, and static benchmarks invite overfitting. He expects the same mapping process to apply to traditional machine learning and additional modalities. The conversation also covers vendor assessments, white-box access, procurement contracts, compliance thresholds, and the work still needed with the EU AI Office.
AI governance starts with knowing what is deployed
Petar Tsankov says companies are moving from a handful of AI applications to around 100 within months, which makes informal oversight unreliable. Organizations first need a centralized process that inventories their systems and identifies which applications matter to the business. This includes distinguishing high business risk from regulatory risk. He describes governance as the starting point because teams cannot manage risks they have not found. Demetrios Brinkmann connects this to the example of
Risk teams are taking responsibility for AI oversight
Tsankov says larger organizations are creating designated teams or extending existing risk functions to cover AI. These teams need people who understand risk management and AI engineering. Individual application owners may already ask specialists to check a model when they know it is important, but Tsankov sees governance shifting that responsibility upward. A central process can identify the most important applications and require checks consistently, rather than depending on a particularly diligent employee or manager to act alone.
Comply turns legal principles into measurable model checks
Tsankov introduces Comply as an open-source, compliance-centered evaluation framework for language models and the EU AI Act. It maps high-level regulatory requirements to technical requirements, then maps those requirements to algorithms and benchmarks that can be run against a model. The framework returns scores between zero and one for the relevant principles. Tsankov says this work addresses a practical problem: organizations face serious penalties but often have no clear way to show how their models perform against the Act. The framework can be used with fine-tuned language models through an inference API.
The framework makes regulation actionable for model vendors
Tsankov rejects the idea that regulation must simply block AI development. He says vendors are more likely to deploy in the EU when requirements can be measured and when they can see which principles need work. Comply evaluated public models from OpenAI, Anthropic, Mistral, Alibaba, and others against EU AI Act principles. Tsankov reports that models generally performed reasonably across many areas, while some compliance scores fell to around 0.5 or 0.6 despite strong capability scores. He describes measurable benchmarks as a way to give developers direction rather than leaving compliance opaque.
Open and closed models show different security trade-offs
Tsankov says closed models often performed better on cybersecurity-related checks, such as preventing prompt leakage and protecting built-in safeguards. This makes sense because users access them through an API and cannot inspect the model. Open models had weaker results in this area because their internals are available and users have more direct control. He also says toxicity results were generally strong, which he attributes to sustained effort from model providers after toxic outputs became a visible public problem. Capability optimization alone, however, left larger gaps on some compliance measures.
Some compliance areas are still hard to test completely
Tsankov uses copyright as an example of an incomplete benchmark. A test can compare model behavior with a selected set of copyrighted books, but nobody has a complete view of all copyrighted material used in training. Auditors can test whether a model reproduces specific content, yet access to training data remains limited and vendors may treat it as core intellectual property. He expects procurement contracts to ask for stronger assessment rights, including ways to run checks locally at the vendor and expose only relevant compliance results to the customer.
Static benchmarks create a direct overfitting problem
Tsankov agrees that models can overfit static compliance benchmarks, especially when providers know which tests regulators or auditors will use. He says evaluation frameworks should be dynamic, adapt their tests based on model behavior, and sometimes restrict how often a benchmark can be run. A static collection of prompts is easy to memorize or include in training data. Dynamic testing makes it harder to optimize for the test without addressing the underlying issue. The benchmark design therefore matters as much as the score it produces.
The Act contains principles that do not yet map cleanly to tests
Tsankov says explainability and interpretability are examples of principles that lack a well-defined technical evaluation method. The EU AI Act was developed in a waterfall fashion, with high-level legal requirements defined before their technical meaning was fully worked out. He argues that future regulation should develop the legal and technical parts more closely together. Compliance work needs to identify what must be checked, choose an evaluation method, and make that method comprehensive enough to distinguish between models. Fairness benchmarks, for example, often gave models similar scores without proving that they were equally fair.
Compliance work will extend beyond language models
Tsankov says Comply's underlying mapping can be extended to multimodal models, although the current implementation focuses on language models. The same process also applies to traditional machine learning systems such as salary prediction, recruitment, fraud detection, and recommender models. For a recommender system, robustness could be tested by measuring whether a small input change causes a large output change. The broader challenge is translating business requirements into technical checks. A Swiss bank's car-price model, for example, had business risk tied to prediction accuracy and data quality rather than only to regulatory compliance.
"You have to take the regulation, the high-level regulatory requirements, then map those into, translate those into technical requirements."Petar Tsankov13:15
Who should watch
You are responsible for AI governance and need a way to inventory deployed systems, assign risk, and decide which applications require review.
Your team builds or buys language models in the EU and needs to turn broad regulatory principles into tests that developers and auditors can run.
You are designing model evaluations and need to account for benchmark overfitting, incomplete copyright checks, or business risks that regulation does not cover.
