# Colchix > Colchix is the AI Governance OS powered by agents that helps organizations move at AI-speed safely. ARGUS discovers AI usage and shadow AI, TALOS protects sensitive data at runtime, and ATHENA turns everyday activity into compliance and audit evidence, all powered by THEMIS. Together they bring visibility, protection and auditability to AI usage across employees and AI agents, in one platform. Colchix works within the AI tools and LLMs teams already use, so nobody moves to a separate workspace: once the local agent and browser extension are installed, people keep working as usual. It starts from European requirements, with a global approach to AI governance: hosted in your region, prompts never stored, privacy by design. The agents, the model under them and the platform: - ARGUS, AI Discovery Agent: discovers AI usage beyond the approved tools, including shadow AI and personal AI accounts used for work, across employees, AI agents and AI-enabled software, and brings it into one AI inventory. - TALOS, AI Data Protection Agent: detects, masks or tokenizes sensitive data at runtime, before it reaches AI tools, in approved tools and shadow AI alike, so teams keep using AI. - ATHENA, AI Compliance Agent: turns observed AI activity into structured audit trails and compliance evidence, for frameworks such as the EU AI Act, the GDPR, ISO 42001 and the NIST AI Risk Management Framework. - THEMIS, System One² AI model: Colchix's own AI model, which powers every agent. - Colchix OS, AI Governance OS: the platform the agents run on. For any sector, including healthcare, banking & finance, insurance, legal, manufacturing, public sector and tech. Colchix B.V., John M. Keynesplein 10, 1066 EP Amsterdam, The Netherlands. hello@colchix.com The Colchix blog (https://colchix.com/blog), on shadow AI, the EU AI Act, GDPR and runtime governance for enterprise AI: every article in full, newest first. ## K11 Consulting and Colchix: Bringing Operational AI Governance to European Organisations > K11 Consulting and Colchix are combining AI governance expertise with operational AI visibility, Shadow AI discovery, runtime data protection and audit-ready evidence for European organisations. Colchix Team & Gianni Valerio, CEO · Published 25 September 2026 · Updated 12 October 2026 · Partnerships · 6 min read **In short:** K11 Consulting and Colchix are working together to close the gap between AI governance on paper and AI use in practice. K11 brings the organisational, regulatory and governance expertise, including External AI Officer services; Colchix adds the operational layer: discovering real AI usage and Shadow AI, protecting sensitive information at runtime and keeping evidence of AI activity. AI governance is no longer just about writing a policy or creating a list of approved tools. Organisations increasingly need to understand which AI systems are being used, who is using them, what data is involved, who is responsible for each use case and how those decisions are documented over time. At the same time, AI adoption rarely happens through a single controlled process. Employees experiment with new tools. Teams adopt specialised applications. Personal accounts sit outside standard enterprise controls. Existing software introduces new AI features without necessarily going through a new procurement or governance cycle. This creates a growing gap between governance on paper and AI usage in practice. This is why K11 Consulting and Colchix are working together. K11 brings the organisational, regulatory and governance expertise required to build practical AI governance structures. Colchix adds the operational layer needed to understand how AI is actually being used and to connect governance decisions with real activity. K11 helps organisations establish and operate AI governance. Colchix helps keep that governance connected to reality. ### K11 Consulting: turning regulatory requirements into operating structures K11 Consulting works across AI governance, data protection, information security, compliance and regulatory implementation. A central part of its AI offering is the External AI Officer. The role is designed to coordinate AI governance across management, IT, data protection, information security and business teams, creating a clear point of responsibility for how AI is introduced and managed inside an organisation. In practice, K11 supports companies across the lifecycle of AI governance. This includes: - establishing and maintaining AI inventories; - creating and managing internal AI policies; - assessing AI systems and their risks; - preparing technical and governance documentation; - supporting conformity assessments and regulatory communication where required; - delivering AI competency training; - defining roles and permission models; - helping organisations develop and implement an AI strategy; - preparing governance structures for ISO 42001. K11 also works beyond AI-specific governance. Its data protection practice supports organisations with GDPR implementation, privacy management structures, technical and organisational measures, policies, training and external Data Protection Officer services. Its information-security work includes ISMS implementation, external information-security roles, security policies, risk analysis, audit preparation and requirements such as NIS2 and DORA. This matters because AI governance rarely belongs to one department. A new AI application can create questions for technology, privacy, information security, compliance, management and individual business teams at the same time. K11 helps organisations connect those functions and turn regulatory requirements into responsibilities, processes and decisions that can actually operate day to day. ### The operational challenge: knowing what is really happening That governance structure depends on accurate information. An organisation may maintain an official AI inventory and still have additional AI usage taking place outside it. An employee might use a personal ChatGPT or Claude account. A department might adopt an AI meeting assistant. A SaaS platform already used by the company might introduce a generative AI feature. None of those situations automatically tells the organisation whether the use is acceptable or problematic. But they do create a basic governance problem if the organisation does not know that the usage exists. This is where Colchix adds the operational layer. Through [ARGUS](https://colchix.com/agents/argus), [TALOS](https://colchix.com/agents/talos) and [ATHENA](https://colchix.com/agents/athena), Colchix helps organisations [discover real AI usage and Shadow AI](https://colchix.com/blog/what-is-shadow-ai), protect sensitive information at runtime and maintain evidence around AI activity and governance controls. The goal is not to replace the governance work already being done. It is to give that work a clearer view of operational reality. ### Why K11 and Colchix fit together Discovering an AI application is not the same as governing it. A technical signal still needs interpretation. If a new AI tool appears inside an organisation, someone needs to understand: - why employees are using it; - what information is being processed; - whether the use case is already covered by policy; - whether privacy or security teams need to be involved; - whether the AI inventory should be updated; - whether additional controls are required; - and ultimately whether the tool should be approved, restricted, replaced or monitored. **Colchix provides visibility into what is happening. K11 helps organisations determine what should happen next.** That creates a practical operating model: Discover → Assess → Decide → Govern For an AI Officer, operational visibility can help maintain a more accurate AI inventory and identify which applications or use cases require attention. For a DPO, it can provide additional context around where personal data may be processed and which providers or safeguards need review. For information-security teams, it can help identify AI services appearing outside established processes. For management, it can provide a clearer view of how AI adoption is evolving across the organisation. ### A practical example Consider an organisation that has formally approved one enterprise AI assistant. Over time, employees begin using several additional tools: an AI meeting assistant, a translation service and another generative AI application for preparing commercial material. The first challenge is visibility. Colchix can help surface that usage and show that the organisation's operational AI landscape is broader than its existing inventory suggests. The next challenge is governance. K11 can help assess the individual use cases, identify the relevant privacy, security and regulatory questions, update the AI inventory and establish the appropriate response. One application might be approved after assessment. Another might require additional safeguards. A third may duplicate functionality already available through an approved enterprise platform. The important point is that the organisation can move from an unknown application to a structured governance decision. ### AI Officer services supported by operational visibility The External AI Officer model is one of the clearest areas where the two approaches complement one another. K11's AI Officer work brings together governance activities that might otherwise remain fragmented across different teams: inventory management, policies, documentation, training, assessments and communication between management, IT, privacy and business functions. Operational visibility can strengthen that work. Instead of relying exclusively on periodic questionnaires, procurement records or manually reported AI usage, organisations can gain an additional source of information about the tools actually appearing across the business. That allows the governance process to become more continuous. The same principle applies to K11's data-protection and information-security work: better operational information can help professionals focus their assessment on the systems and behaviours that actually exist. ### From Shadow AI to governed AI adoption Shadow AI should not automatically be treated as evidence of employee misconduct. It can also reveal unmet business needs. Employees may adopt a new tool because it solves a problem faster, offers functionality that approved systems do not provide or simply appeared before the organisation had time to evaluate it. The governance objective is therefore not merely to discover and block. It is to understand, assess and make an informed decision. This is where the combination of K11's governance expertise and Colchix's operational visibility becomes useful. K11 provides the structures, expertise and ongoing governance processes required to manage AI responsibly. Colchix provides a technical layer that helps those processes stay connected to real AI adoption. ### From governance on paper to governance in practice AI adoption will continue to evolve faster than annual reviews and static inventories. European organisations therefore need governance models that can evolve with it. K11 brings the organisational side: AI Officer services, governance processes, policies, inventories, assessments, training, privacy, information security and regulatory implementation. Colchix brings the operational side: AI visibility, Shadow AI discovery, runtime protection and governance evidence. Together, the partnership is built around a straightforward idea: help organisations move from AI governance on paper to AI governance that works in practice. For a broader look at how advisory, reseller, service and technology partners work with AI governance software, see our guide to [AI governance partner and reseller programs](https://colchix.com/blog/ai-governance-partner-reseller-program). ### Learn more #### K11 Consulting Learn more about K11 Consulting's work across External AI Officer services, AI governance, AI training, data protection, information security and regulatory implementation. [Visit K11 Consulting →](https://www.k11-consulting.com/en/) #### Colchix Partner Program Learn how Colchix works with AI governance, privacy, security and technology professionals to bring operational AI governance into the organisations they support. [Explore Colchix Partners →](https://colchix.com/partners) ### Frequently asked questions #### What is the K11 Consulting and Colchix partnership? K11 Consulting and Colchix work together to help European organisations move from AI governance on paper to AI governance that works in practice. K11 provides the organisational side: AI Officer services, governance processes, policies, inventories, assessments, training, privacy, information security and regulatory implementation. Colchix provides the operational side: AI visibility, Shadow AI discovery, runtime protection and governance evidence. #### What is an External AI Officer? A role K11 offers to coordinate AI governance across management, IT, data protection, information security and business teams, creating a clear point of responsibility for how AI is introduced and managed inside an organisation, from AI inventories and policies to risk assessments, documentation and training. #### How does operational visibility support AI governance? It gives governance work a clearer view of reality. Instead of relying only on questionnaires, procurement records or self-reported usage, organisations gain an additional source of information about the AI tools actually appearing across the business, so an unknown application can move to a structured governance decision: discover, assess, decide, govern. --- Source: https://colchix.com/blog/k11-consulting-colchix-ai-governance-partnership ## AI Governance Partner & Reseller Programs: How Advisors, Consultants and System Integrators Can Build a New Revenue Stream > AI governance is becoming a new channel opportunity for advisors, consultancies, system integrators and managed service providers. Here is how partner, reseller and referral models work — and how they can create new client value and revenue. Colchix Team & Gianni Valerio, CEO · Published 24 September 2026 · Updated 12 October 2026 · Partnerships · 8 min read **An AI governance partner or reseller program allows advisors, consultancies, system integrators and technology providers to use AI governance software in their client work, introduce it into customer accounts and participate commercially in the business they help generate.** AI governance is becoming a channel opportunity because organisations increasingly need operational help, not only policies. They need AI inventories, Shadow AI discovery, risk assessment, privacy and security controls, and evidence that governance is working. The professionals they already trust — AI governance advisors, DPOs, vCISOs, CAIOs, consultancies, system integrators and managed service providers — are well placed to deliver that help. **In short** - An AI governance partner program is a structured way for third parties to use, recommend, resell or integrate AI governance software. - It is aimed at AI governance advisors, CAIOs, DPOs, vCISOs, fractional CTOs, consultancies, software houses, system integrators, MSPs, MSSPs and technology companies. - Partners use the software as an operational layer underneath their advisory, implementation or managed services. - Commercial participation usually takes the form of referral commissions, reseller margins, professional services or recurring managed services. The key distinction is that AI governance partners do not only sell software. The strongest models combine operational technology with the governance, privacy, security, implementation and managed services partners already provide. This makes AI governance both a software channel opportunity and a professional-services opportunity. ### What is an AI governance partner program? An AI governance partner program is a formal arrangement in which an AI governance software vendor works with external professionals and organisations to bring its platform to customers. Partners gain access to the product, enablement and support; the vendor gains reach into organisations that partners already serve. Programs typically include several partner types: - **Advisory partners** — independent advisors who use the platform inside client engagements. - **Referral partners** — professionals who introduce opportunities to the vendor. - **Reseller partners** — firms that include the software in their own customer offering. - **Service and implementation partners** — firms that deploy, configure and integrate the platform. - **Managed service providers** — MSPs and MSSPs that deliver ongoing governance as a service. - **Technology alliance partners** — software companies that integrate or build joint solutions. Not every model works the same way. The level of commitment, the commercial relationship and who owns day-to-day delivery differ between a referral arrangement and a full reseller or managed-service model. ### Why AI governance is becoming a channel opportunity Demand for AI governance is growing because AI adoption inside organisations is moving faster than traditional governance processes. Several forces are driving this: - **Rapid enterprise AI adoption** — generative AI tools are increasingly used across business functions. - **Shadow AI** — employees adopt AI tools without approval or oversight. See [what Shadow AI is](https://colchix.com/blog/what-is-shadow-ai) and why it matters. - **Personal and unmanaged accounts** — AI usage often happens outside enterprise identity and security controls. - **Embedded AI functionality** — existing software adds AI features without a new procurement cycle. - **EU AI Act obligations** — depending on their role and use case, organisations may need to identify, classify and govern relevant AI systems. Our [AI Act enforcement timeline](https://colchix.com/blog/ai-act-enforcement-timeline) summarises the key dates. - **GDPR and sensitive-data concerns** — personal and confidential data can reach external AI models. - **AI management systems** — organisations are increasingly evaluating structured approaches such as ISO 42001. - **Growing responsibility** for CAIOs, DPOs, CISOs and governance teams. As a result, organisations increasingly need both expert advice and operational AI governance software. Advice defines what should happen. Technology shows what is actually happening and helps enforce and evidence the decisions. Partners who can combine both are in a strong position. ### Who can become an AI governance partner or reseller? Almost any professional or organisation that already supports companies with AI, privacy, security or technology can benefit from an AI governance partner model. The fit differs by role. #### AI Governance Advisors and CAIOs AI governance advisors and CAIOs can use a partner platform as the operational layer of their engagements and participate in the business they help generate. It lets them replace manual questionnaires with real usage data. It supports AI inventories, risk classification and ongoing oversight, and gives advisors continuous evidence between periodic reviews. #### DPOs and Privacy Professionals DPOs and privacy professionals can use AI governance tools to ground privacy work in real AI usage data. AI usage visibility supports AI inventories, data protection impact assessments and privacy reviews. It shows which AI tools are in use and where personal or sensitive data may be exposed, which strengthens the documentation privacy teams already produce. #### vCISOs and Security Advisors vCISOs and security advisors can add AI governance to the security services they already deliver. Shadow AI and unmanaged AI usage are now part of the security conversation. Operational AI governance tools help identify unapproved tools, personal accounts and data leakage risks, and add runtime controls. Our article on [Shadow AI detection](https://colchix.com/blog/shadow-ai-detection) covers the security angle in more detail. #### Fractional CTOs and Technology Leaders Fractional CTOs and technology leaders can introduce the same governance capabilities across every organisation they support. A multi-client AI governance platform lets them introduce consistent governance capabilities across each organisation without building separate tooling for each one, since they often support several organisations at once. #### Consultancies and Software Houses Consultancies and software houses can turn AI governance into an additional service line or product offering, as service or reseller partners. It complements existing work in digital transformation, compliance, data and AI implementation projects. #### System Integrators, MSPs and MSSPs System integrators, MSPs and MSSPs can resell, implement and operate AI governance software as part of their existing customer services. They can deploy the platform, integrate it with identity, security and cloud environments, and deliver ongoing AI monitoring and governance reporting as a recurring service. #### Technology Companies Technology companies can become technology partners by integrating with an AI governance platform or building joint solutions. This applies to AI, security, cloud, identity and compliance platforms. Integrations and joint solutions create stronger combined offerings for enterprise customers than either product delivers alone. ### How do AI governance partners make money? AI governance partners typically earn through a combination of software-related revenue and the professional services they deliver around the software. Partner economics generally come from two sources: participation in the software business and the partner's own professional or managed services. The main commercial models are: #### Referral commission The partner introduces an opportunity and receives a commission when the business closes. #### Reseller margin The partner incorporates the platform into a broader customer offering and participates commercially in the software revenue. #### Advisory and implementation services The partner charges for governance, implementation, assessment, configuration, training or ongoing advisory services around the platform. #### Managed governance services MSPs, MSSPs or specialist consultancies build recurring services around ongoing AI monitoring, governance and reporting. #### Internal use that expands into client work Advisors first learn and use a platform internally, then introduce it into customer environments once they understand how it fits. **The strongest partner models combine software economics with the professional services and ongoing client work partners already deliver.** ### Referral partner vs reseller vs service partner vs technology partner The main difference between partner models is how deeply the partner is involved in selling, delivering and operating the platform. | Partner model | Typical role | How they use the platform | Typical commercial model | | --- | --- | --- | --- | | **Advisory / Referral Partner** | Independent advisor, DPO, vCISO, CAIO | Uses it in engagements and introduces it to clients | Referral commission plus own advisory fees | | **Service Partner** | Consultancy or implementation firm | Deploys, configures and trains | Implementation and advisory services | | **Reseller Partner** | Software house, system integrator, consultancy | Includes it in its own customer offering | Reseller margin plus services | | **MSP / MSSP** | Managed IT or security provider | Operates it continuously across customers | Recurring managed-service fees | | **Technology Partner** | AI, security, cloud, identity or compliance platform | Integrates or builds joint solutions | Joint go-to-market and combined offerings | ### How AI governance software fits into client engagements AI governance software fits into client engagements as the operational layer underneath advisory work. A practical workflow looks like this: 1. **Discover real AI usage** across employees, teams and applications. 2. **Identify Shadow AI and unmanaged tools**, including personal accounts. 3. **Assess risk and governance requirements** against regulation and internal policy. 4. **Define approval, restriction or remediation decisions** for each tool and use case. 5. **Apply technical and organisational controls**, such as [tokenization or redaction](https://colchix.com/blog/tokenization-vs-redaction) of sensitive data before it reaches external models. 6. **Maintain evidence over time** through continuous records and audit-ready reporting. The governance professional or responsible team owns the judgement; the software supplies visibility, controls and evidence. This is what [runtime AI governance](https://colchix.com/blog/runtime-ai-governance) means in practice: governance that keeps working between reviews. ### What should you look for in an AI governance partner program? A partner program should be evaluated on both product quality and channel quality. A strong platform is not enough if partners cannot test it, deploy it reliably, support multiple clients or understand how the commercial model works. Useful evaluation criteria include: - the ability to test the product before bringing it to clients; - partner enablement and training; - clear commercial economics; - support for client deployments; - scalable multi-client use; - strong reporting and evidence; - Shadow AI visibility; - runtime controls; - a model-agnostic architecture; - deployment options appropriate for European organisations; - sales and technical support; - co-marketing opportunities. ### The Colchix Partner & Reseller Program Colchix is an AI governance platform built for European organisations. Its Partner & Reseller Program is designed for professionals and companies that already support customers across AI governance, privacy, security and technology. The program has three partner models: #### Advisory Partners AI Governance Advisors, CAIOs, vCISOs, DPOs, fractional CTOs, privacy and legal professionals. Advisory Partners use Colchix inside client engagements and participate commercially in business they help generate. #### Service & Reseller Partners Software houses, system integrators, consultancies, MSPs and MSSPs. Service & Reseller Partners add Colchix to existing offerings and introduce it into customer accounts. #### Technology Partners AI, security, cloud, identity and compliance platforms. Technology Partners build integrations and joint solutions around operational AI governance. [Explore the Colchix Partner & Reseller Program →](https://colchix.com/partners) ### How the Colchix partner model works The Colchix partner model starts with product familiarity before moving into client delivery and commercial participation. 1. Test Colchix. 2. Understand how it fits your work. 3. Use it internally, for evaluation or in relevant engagements. 4. Introduce Colchix into client environments. 5. Colchix supports deployment and onboarding. 6. Partners participate commercially in business they help generate. Commercial terms are discussed individually during the partner conversation. ### Frequently asked questions #### What is an AI governance reseller program? An AI governance reseller program lets consultancies, system integrators and service providers include AI governance software in their own customer offering and participate commercially in the software revenue. Resellers usually combine the platform with their own implementation, advisory or managed services. #### Can consultants resell AI governance software? Yes, consultants can resell AI governance software where the vendor offers a reseller or referral model. They typically either introduce the software and earn a referral commission, or include it in a broader engagement as a reseller alongside their own advisory and implementation work. In both cases, the software supplies visibility and evidence while the consultant supplies the governance expertise. #### Can DPOs use AI governance platforms with their clients? Yes. External and in-house DPOs can use AI usage visibility to support AI inventories, data protection impact assessments and privacy reviews. It gives them evidence of which AI tools are actually used and what data may be involved, rather than relying only on self-reported questionnaires. #### Can vCISOs offer AI governance as a service? Yes. vCISOs increasingly treat Shadow AI, unmanaged AI accounts and sensitive-data exposure as part of the security risk picture. With operational AI governance software, they can add continuous AI visibility, controls and reporting to the security services they already deliver. #### Can system integrators sell AI governance software? Yes, system integrators can sell AI governance software through reseller or service partner models. They can deploy, configure and integrate the platform within customer environments and combine it with existing identity, security, cloud and data projects. This lets them add AI governance to accounts they already serve without building the technology themselves. #### How do AI governance partners make money? AI governance partners typically make money through referral commissions, reseller margins, advisory and implementation services, and recurring managed governance services. Partner economics come from two sources: participation in the software business and the partner's own professional or managed services. The strongest models combine software economics with the client work partners already deliver. #### What is the difference between a referral partner and a reseller? A referral partner introduces an opportunity and receives a commission when the vendor closes the business. A reseller includes the software in its own customer offering, usually manages the commercial relationship and participates in the software revenue through a margin. #### Do partners need to use the product before selling it? Not every partner program requires it, but testing the platform before introducing it to clients is good practice. It helps partners understand where the product fits, demonstrate it credibly and set realistic expectations. Colchix expects partners to become familiar with the platform before actively bringing it into customer environments. #### Can MSPs and MSSPs offer AI governance services? Yes, MSPs and MSSPs can offer AI governance as a recurring managed service. They can build services around ongoing AI usage monitoring, Shadow AI discovery, policy enforcement, runtime controls and periodic governance reporting, delivered across multiple customer environments from one platform. #### Is AI governance a good service opportunity for consultants? AI governance can become an additional service line for consultants who already work across privacy, security, compliance, AI or digital transformation. Software can provide operational visibility and evidence, while the consultant provides assessment, implementation and ongoing advisory services. #### How can a consultancy add AI governance to its existing offering? A consultancy can add AI governance by combining a partner platform with its existing advisory, implementation or managed services. The software provides capabilities such as AI inventory, Shadow AI visibility, controls and evidence, while the consultancy delivers governance design, assessment, implementation and ongoing support. #### What is an AI Act partner program? An AI Act partner program is a partner program aimed at advisors and service providers who help organisations prepare for and operate under the EU AI Act. In practice, it usually overlaps with an AI governance partner program, because AI Act readiness depends on AI inventories, risk assessment, controls and evidence. #### Does Colchix have an AI governance reseller program? Yes, Colchix runs a Partner & Reseller Program. It covers Advisory Partners, Service & Reseller Partners and Technology Partners, serving AI governance advisors, DPOs, vCISOs, CAIOs, consultancies, system integrators, MSPs, MSSPs and technology platforms. Details are available on the Colchix Partners page, and commercial terms are discussed individually with each partner. [Become a Colchix Partner](https://colchix.com/partners) --- Source: https://colchix.com/blog/ai-governance-partner-reseller-program ## Introducing THEMIS: Europe’s Enterprise-Ready System One Model for AI Governance > Colchix is building THEMIS, a sovereign System One model for real-time data protection, typed AI decisions and enterprise AI governance in Europe. Colchix Team & Gabriele Salvo, CTO · Published 23 September 2026 · Updated 12 October 2026 · System One AI · 11 min read **In short:** Colchix is building THEMIS, a sovereign System One model for real-time data protection and AI governance in Europe. It begins with one demanding enterprise task: finding sensitive information, understanding whether it requires protection and returning an allow, mask, block or escalate decision before data reaches an external AI system. Large language models changed how people interact with software. System One models are beginning to change how software itself makes decisions. [Jev demonstrated the potential](https://colchix.com/blog/what-is-jev-system-one-model) of models designed for fast, typed and probabilistic judgments instead of open-ended text generation. The emerging open-source ecosystem has shown that similar decision models can also run locally. But European enterprises still face a gap. The models that decide quickly do not necessarily locate the exact information that must be protected. The systems that locate sensitive values may not judge them in context. General-purpose LLMs can perform both tasks, but may be too slow or operationally expensive for an invisible protection layer that must evaluate every prompt and attachment in real time. And model capability alone does not provide European data residency, zero data retention, private deployment, policy enforcement or audit evidence. THEMIS is being developed to bring those requirements together. > **Starting with PII. Building Europe’s decision layer for enterprise AI.** THEMIS is currently under development. This article describes its intended product direction and the measurable acceptance criteria Colchix has established before release. It does not present projected performance as achieved benchmark results. ### What is THEMIS? THEMIS is Colchix’s sovereign, enterprise-ready System One model for real-time data protection and AI governance. Its first use case is runtime sensitive-data protection. Given a prompt, message, document or application state, THEMIS is being designed to: 1. identify the exact boundaries of personal, confidential and regulated information; 2. determine whether each value requires protection in its context; 3. return a bounded **allow, mask, block or escalate** decision; 4. expose useful confidence so uncertain cases can be handled safely; 5. operate as part of a European-controlled governance and audit layer. This is different from asking a chat model to generate a compliance assessment. THEMIS is intended to return machine-readable decisions that software can act on before information leaves an approved environment. The initial model is focused on sensitive data because runtime masking exposes the hardest combination of requirements: precise location, contextual judgment, calibrated uncertainty, whole-file reach and low latency. The longer-term direction is broader: a general European decision model and specialised System One models for regulated enterprise workflows. ### Why existing approaches leave a gap Protecting an enterprise AI interaction requires more than recognising that sensitive information exists somewhere in the text. A production system must answer four questions: - **What exactly is sensitive?** The complete value must be located, not merely detected. - **Does it require protection here?** Context determines whether a value is sensitive or a harmless look-alike. - **Can the entire input be evaluated?** Contracts, exports and code files cannot be silently truncated. - **Can the decision happen before transmission?** A protection layer must operate without destroying the user experience. Different technologies solve different parts of this problem. #### Pattern matching is fast but narrow Regular expressions are deterministic, inexpensive and excellent for known formats. They can identify many email addresses, phone numbers, identification numbers and financial patterns. They cannot reliably understand a project codename, a medical condition described in ordinary language, a person referred to indirectly or a company-specific sensitive term that does not follow a fixed format. #### Entity extraction models locate values but may lack judgment PII and named-entity models can return spans inside text. They are useful when the categories are known and the values resemble their training data. But locating a possible entity is not the same as deciding whether masking it is necessary or whether masking would break the request. Boundary errors also matter: replacing only part of an address, health condition or identifier still leaks the original information. #### Current System One models decide but do not necessarily locate Decision models such as Jev are designed to return typed judgments and probabilities. That is valuable for classification, routing and policy checks. However, deciding that a message contains sensitive information does not reveal the exact characters that a masking system must replace. Open decision models may also operate with limited context windows or require additional serving and governance infrastructure. #### General-purpose LLMs can reach more text, but slowly A general LLM can often find values, judge them in context and return structured output. It can also process categories that were not anticipated by a fixed pattern library. The trade-off is latency, cost and operational dependence on a generative system. A runtime protection layer must evaluate interactions continuously, often without users noticing that another model call has occurred. ### What Colchix measured To define the release bar for THEMIS, Colchix built an internal synthetic benchmark for runtime masking. The current test set contains: - **98 workplace-style passages**; - **241 annotated sensitive values**; - **137 harmless look-alikes**; - examples in **English, German, French and Italian**; - short messages and long inputs, including approximately 16,000-token documents and exports. No customer text is included in the benchmark. The benchmark measures whether a system: - finds every relevant value; - returns the exact boundary required for masking; - judges genuine sensitive values correctly; - leaves harmless look-alikes untouched; - reads the complete input rather than silently truncating it; - completes the task within a usable latency; - keeps the text inside the required jurisdiction. The results below are measurements of currently available approaches. They are not THEMIS results. ### Current benchmark: every available option trades something away On the short-message test, the measured systems protected the following share of 100 sensitive values completely: | Approach | Sensitive values fully protected | Median time per short message | Main limitation | | --- | --- | --- | --- | | Regex patterns | 59 of 100 | Under 1 ms | Finds fixed formats only | | GLiNER2-PII | 70 of 100 | 313 ms | Locates known entity classes but does not provide the complete contextual decision layer | | GLiNER2-PII followed by Jev | 69 of 100 | 697 ms | Chaining two models compounds missed locations and boundary errors | | Gemini 2.5 Flash, one call | 77 of 100 | 769 ms | Most protective measured option, but also the slowest short-message option in the comparison | Jev and Laya were also evaluated as decision models. Both can judge text, but neither independently returns the exact spans required to replace every sensitive value. In the tested setup, Jev took a median 384 ms to read and judge a short message; Laya took approximately 480 ms and was shown only the beginning of longer inputs according to the tested configuration. Long inputs expose another trade-off. Regex processed the tested long input quickly but protected only fixed-format values. GLiNER2-PII protected 84 of 100 annotated values across the approximately 16,000-token attachment test, but the measured workflow took 119 seconds on the local CPU configuration. Gemini completed one long prose document in approximately 17 seconds but returned no result on the customer-style export after 40 minutes in the tested configuration. These figures should not be treated as universal vendor benchmarks. They describe a specific synthetic test set, model versions, prompts, local hardware and service configurations. Performance may change with different data, infrastructure, settings and provider updates. The important finding is architectural: > **The fastest options do not provide sufficient semantic protection, while the most protective measured option is too slow for an invisible real-time layer.** ### Why exact boundaries matter A value is protected only when the entire sensitive span is replaced. If a system masks only part of “Keizersgracht 123, Amsterdam,” the remaining text may still reveal the address. The same applies to a medical condition, an internal project name or an indirect description such as “the woman who joined from the Rotterdam team.” In the measured two-model chain, the largest loss occurred before the final judgment: 1. 100 sensitive values entered the workflow; 2. 90 were located at all; 3. 70 had an exact boundary; 4. 69 were finally judged sensitive and protected. That means 31 of every 100 values still leaked, primarily because values were never found or were only partially located. THEMIS is being designed to train location, boundary precision, judgment and confidence together rather than treating them as disconnected stages. ### The THEMIS release bar Colchix will not describe projected numbers as achieved results. Instead, we are publishing the minimum engineering acceptance criteria THEMIS must clear before its first production release. | Acceptance criterion | THEMIS development target | | --- | --- | | Sensitive values fully protected in short messages | **At least 90 of 100** | | Sensitive values fully protected in long attachments | **At least 90 of 100** | | Exact-boundary accuracy | **At least 92%** | | Harmless look-alikes left untouched | **At least 95%** | | Median processing time for a short message | **Under 100 ms** | | Long-input behaviour | **Reads the complete supported input, returns an explicit error or escalation, and never cuts silently** | | Data location | **European-controlled processing** | | Retention | **Zero retention for protected content by design** | These are **development targets, not benchmark results**. THEMIS has not yet been validated against this acceptance suite. We will publish measured performance only after the model has been trained, frozen and evaluated against a reproducible test protocol. Where possible, results will include model and dataset versions, execution environment, confidence intervals and known limitations. ### Why THEMIS is part of Colchix THEMIS is not being built as an isolated model demo. It is intended to become the decision engine inside the Colchix AI governance platform: - **[ARGUS](https://colchix.com/agents/argus)** discovers which AI tools, accounts and embedded capabilities are being used across the organisation. - **[TALOS](https://colchix.com/agents/talos)** intercepts sensitive data before it reaches an external AI system and applies reversible tokenisation or masking. - **THEMIS** evaluates what requires protection and returns bounded runtime decisions. - **[ATHENA](https://colchix.com/agents/athena)** records policies, decisions, confidence, model versions and audit evidence on European infrastructure. This combination connects model intelligence to an enforceable workflow: 1. observe the AI interaction; 2. identify and evaluate sensitive information; 3. allow, mask, block or escalate; 4. send only the permitted content onward; 5. restore authorised values locally where required; 6. preserve evidence of what happened and why. The model does not replace deterministic policy. THEMIS supplies bounded judgments; Colchix applies organisational rules, thresholds, access controls and human-review paths around them. ### Built for European control European readiness is not a badge added after training. It affects how the system is designed and operated. The intended deployment paths for THEMIS include: - managed serving on European-controlled infrastructure; - single-tenant deployments; - private VPC deployment; - on-premises deployment for organisations with stricter requirements; - locally controlled masking and token vaults; - explicit retention and deletion rules; - pinned model versions and auditable updates. These deployment paths are product direction and are not all generally available today. The goal is to let European enterprises use global AI while keeping control of sensitive information, enforcement and evidence within their chosen boundary. ### From PII protection to a European decision layer PII protection is the first proving ground, not the final category. The THEMIS roadmap is designed to progress in evidence-based stages: #### Phase 1: sensitive-data protection THEMIS operates inside Colchix to locate sensitive information and support runtime masking and policy decisions. #### Phase 2: specialised enterprise workflows Selected design partners define another bounded decision workflow using their own taxonomy and labelled examples. This tests whether the same model approach can generalise beyond PII. #### Phase 3: private customer models Through the planned **THEMIS Foundry**, a customer’s decision schema and approved data can be used to create a specialised model served privately in Europe. #### Phase 4: a broader System One platform Once repeated customer deployments demonstrate a reliable pattern, Colchix intends to offer a broader European platform for creating and operating specialised decision models. Each phase depends on proving the one before it. THEMIS Foundry and self-service model creation are roadmap direction, not currently available products. ### What belongs to Colchix THEMIS is being developed on permissively licensed open foundations, with attribution to their respective maintainers. Colchix is not claiming to have created a new foundation model from scratch. The intended proprietary advantage lies in: - the labelled enterprise data and category system developed for masking; - the objective that trains location, decision quality and calibration together; - the evaluation and acceptance framework; - European serving and deployment controls; - integration with Colchix discovery, protection, policy and audit capabilities; - the additional customer-specific models and workflows built over time. Open foundations make the starting point accessible. The data, training objective, governance system and production workflow determine whether the result solves an enterprise problem. ### Join the THEMIS waitlist THEMIS is currently under development, and Colchix is selecting European design partners for early technical validation. The waitlist is intended for organisations that want: - early access to technical updates and benchmark results; - an opportunity to evaluate THEMIS on an approved enterprise workflow; - private European deployment options; - participation in the design-partner programme; - future access to specialised System One models. > **Join the THEMIS waitlist for technical updates, early access and design-partner opportunities.** ### Frequently asked questions #### Is THEMIS available today? No. THEMIS is currently under development. Colchix has defined the benchmark, product direction and acceptance criteria, but has not yet published achieved model results or general availability. #### Are the THEMIS performance numbers measured? No. The figures listed in the THEMIS acceptance table are development targets, not measured performance. Benchmark figures attributed to Regex, GLiNER2-PII, Jev, Laya and Gemini describe Colchix’s current internal synthetic evaluation of those existing approaches. #### Is THEMIS a fork of Jev? No. Jev is a proprietary model owned by TypeSafe AI. THEMIS is being developed independently by Colchix on permissively licensed open foundations, with its own labelled data, objectives, evaluation criteria and enterprise integration. #### Is THEMIS an LLM? THEMIS is being designed as a System One decision model rather than a conventional chat or text-generation model. Its purpose is to return bounded, machine-readable judgments and exact sensitive-data locations, not open-ended prose. #### Where will THEMIS run? THEMIS is being designed for European-controlled deployment, with planned managed EU, single-tenant, private VPC and on-premises paths. These options are product direction and are not all generally available today. #### What is THEMIS Foundry? THEMIS Foundry is the planned future capability through which an enterprise could turn its decision schema and approved labelled data into a specialised model served privately in Europe. It is part of the roadmap and is not currently available. #### How can an organisation participate? European enterprises, regulated organisations and technical design partners can join the THEMIS waitlist to receive development updates and discuss early validation opportunities with Colchix. ### Methodology and disclosure The current Colchix masking benchmark uses a frozen synthetic dataset containing 98 workplace-style passages, 241 annotated sensitive values and 137 harmless look-alikes across English, German, French and Italian. The test contains no customer text. Each existing tool was evaluated on the same underlying examples, subject to the input and output formats supported by that tool. Local timing measurements were taken on a laptop CPU; hosted-model timing includes the measured API request. Long-input results depend on the tested configuration and should not be generalised beyond it. The dataset was authored internally and currently has one additional blind annotation produced by a model rather than a second human annotator. This is a limitation. Colchix intends to expand the dataset, add independent human review and publish a fuller reproducibility package before making definitive comparative claims. All THEMIS figures in this article are development targets. No THEMIS performance result is claimed. Jev and TypeSafe AI belong to their respective owner. Gemini belongs to Google. GLiNER, Laya and other open-source components belong to their respective maintainers. Colchix is not affiliated with or endorsed by these organisations or projects. ### Sources - [TypeSafe AI: Introducing System One Models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [TypeSafe AI technical documentation](https://docs.typesafe.ai/introduction) - [Laya open-source implementation](https://github.com/receptron/laya) - [Arbiter: local Jev-compatible decision-model serving](https://github.com/0xBakeer/arbiter) - Colchix internal synthetic masking benchmark, version current as of 23 September 2026. A fuller methodology and reproducibility package is planned. **Related:** [What Is Jev? System One Models vs LLMs Explained](https://colchix.com/blog/what-is-jev-system-one-model) **Related:** [Can European Enterprises Use Jev? GDPR, Data Residency and EU Readiness Explained](https://colchix.com/blog/can-european-enterprises-use-jev) **Related:** [Is There a European Alternative to Jev? System One AI, Sovereignty and THEMIS](https://colchix.com/blog/european-alternative-to-jev) --- Source: https://colchix.com/blog/introducing-themis ## System One AI for Enterprise: Governance, Security and Real-Time Decision Use Cases > Learn how System One AI models can be used in enterprise workflows for routing, security, governance, sensitive-data detection and real-time decisions. Colchix Team & Gabriele Salvo, CTO · Published 23 September 2026 · Updated 12 October 2026 · System One AI · 8 min read System One AI models are designed to make fast, structured decisions inside software rather than generate open-ended text for people. In enterprise environments, that makes them particularly relevant for workflows such as classification, routing, risk scoring, security checks, sensitive-data detection and policy enforcement. The category is new. Jev, introduced by [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev) in September 2026, is the first public model explicitly positioned as a System One model. TypeSafe describes System One models as machine-native models that return typed decisions with probabilities and confidence rather than free-form strings. For background on Jev itself, see our explainer on [what Jev is and how System One models differ from LLMs](https://colchix.com/blog/what-is-jev-system-one-model). This article focuses on something different: where System One AI fits in enterprise workflows, and what it takes to govern and secure it. **In short** - System One models return structured decisions rather than free-form text. - They are designed to sit directly inside software workflows and automation. - Useful enterprise tasks include classify, route, score, detect, verify and gate. - Governance becomes especially important when AI decisions trigger automated actions. ### What is System One AI? System One AI describes models designed primarily for machine-consumable decisions rather than open-ended conversation. Instead of writing a paragraph that a person (or another program) has to interpret, a System One model answers a question whose possible outputs are defined in advance: pick one of these categories, give a score, return yes or no. A few characteristics define the category: - **Machine-oriented output.** The answer is designed to be consumed by software, not read by a human. - **Predefined output types.** The shape of the answer — a label, a number, a boolean — is fixed before the model is called. - **Probabilities and confidence.** The model can return how likely each answer is, not just the answer itself. - **Direct consumption.** Because the output is typed, code can act on it without parsing generated text. - **Fast inference.** Small, bounded outputs can make real-time workflows practical. Jev is currently the public example of this emerging category. TypeSafe AI makes specific claims about Jev’s speed, cost and calibration; those are TypeSafe’s claims, and enterprises should evaluate them against their own tasks. ### System One AI vs traditional LLM workflows | Dimension | Traditional LLM | System One model | | --- | --- | --- | | **Primary output** | Generated text | Typed decision | | **Main consumer** | Human or agent | Software | | **Integration** | Parse/validate generated output | Structured output defined in advance | | **Typical task** | Generate, explain, converse | Classify, score, route, verify | | **Uncertainty** | Often implicit | Can be returned explicitly as probability/confidence | | **Workflow role** | Flexible reasoning/generation | Decision component inside code | One important caveat: System One models are not replacements for LLMs in every task. They are better understood as a different AI primitive for situations where software needs a bounded decision rather than generated content. ### Where System One AI fits in enterprise workflows The most useful way to think about System One AI is as a decision component that sits at specific points in a workflow. The examples below are illustrative; each one still needs to be evaluated for accuracy on the organisation’s own data. #### Classification and routing Many enterprise processes start with a question of “what is this, and where should it go?” Examples include: - routing support tickets to the right team; - classifying incoming business requests; - selecting the next step in a workflow; - deciding which system or model should handle a request. #### Risk scoring and escalation Scores with confidence make it easier to decide what needs attention. Examples include: - assigning risk levels to transactions, requests or events; - deciding whether an event needs human review; - escalating low-confidence decisions; - prioritising alerts. #### Sensitive-data detection A decision model can be used to answer a narrow question before content moves further: does this text contain personal data, confidential business information, credentials or other protected data? If the answer is yes, the surrounding system can apply controls before another model — for example an external LLM — ever receives the content. This is a use case, not a built-in feature of the category. Not every System One model provides sensitive-data detection; a model has to be built and evaluated for that task. #### AI security and guardrails As more AI is embedded in products and internal tools, security teams need fast checks around AI interactions. Examples include: - assessing prompts or outputs; - detecting suspicious or disallowed interactions; - deciding whether an AI request should proceed; - verifying another model’s output; - triggering additional controls. #### AI agent governance AI agents propose and take actions. A decision layer can sit between the proposal and the action. Examples include: - approving or rejecting proposed actions; - routing agent decisions; - setting confidence thresholds for autonomous action; - requiring human review for uncertain or sensitive actions. #### Large-scale data processing Some tasks involve applying the same decision to millions of records: labelling documents, flagging records for review, or checking data against a policy. Free-form generation is often unnecessarily expensive for this and produces output that is harder to integrate. A structured decision, applied repeatedly, fits the job more naturally and can be written straight into a database or pipeline. ### Why confidence matters in enterprise automation A decision is more useful operationally when software knows not only the answer but also how certain the model is. Confidence turns a single answer into a policy choice: - **High confidence** → proceed automatically; - **Medium confidence** → apply additional checks; - **Low confidence** → send to human review. This only works if confidence is meaningful. For a well-calibrated model, predictions made at roughly 90% confidence should be correct at roughly that rate over a sufficiently large set of comparable cases. TypeSafe explicitly positions Jev around calibrated probabilities and confidence; its reasoning is set out in its [official introduction to System One models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev). As with any vendor claim, calibration should be tested on the decisions an organisation actually needs to make. ### System One AI for governance and security The key point is simple: the closer AI gets to directly controlling software workflows, the more important governance becomes. When a model’s output is read by a person, that person acts as an informal check. When a typed decision flows straight into code, there may be no one looking before something happens. Operationally, that means organisations need clear answers to questions such as: - who defines the decision boundaries and the allowed outputs; - which models are approved for which decisions; - what data the decision model can access; - which confidence thresholds allow autonomous action; - when and how decisions are escalated to humans; - how decisions are logged for audit; - how model and policy versions are tracked; - how false positives and false negatives are monitored; - what evidence shows why a particular control fired. For the regulatory angle — roles, intended purpose and high-risk use cases — see [Jev and the EU AI Act](https://colchix.com/blog/jev-eu-ai-act). ### System One AI and real-time data protection One concrete architecture shows how a decision model can protect data in real time: 1. An employee or application sends a prompt or request. 2. A fast decision model inspects the relevant content. 3. It identifies sensitive elements or determines whether controls are required. 4. The system masks, tokenizes, blocks or routes the request according to policy. 5. The underlying AI application receives only the permitted content. This is one possible System One architecture, not a capability automatically provided by every System One model. The choice between masking techniques matters too — see [tokenization vs redaction](https://colchix.com/blog/tokenization-vs-redaction) — and the broader pattern of enforcing policy at the moment of use is covered in [runtime AI governance](https://colchix.com/blog/runtime-ai-governance). ### When should enterprises use System One AI instead of an LLM? Use a System One model when: - the possible outputs are known in advance; - software must act on the answer; - low latency matters; - the task is repeated frequently; - uncertainty needs to be quantified; - a deterministic output structure is important. Prefer an LLM when: - the output needs to be open-ended; - generation, explanation or conversation is the goal; - the task requires long-form synthesis; - a human is expected to interpret the response. Many enterprise systems will use both: a System One model to decide, route and gate, and an LLM to generate where generation is genuinely needed. ### What enterprises should evaluate before adopting a System One model - accuracy for the specific decision task; - calibration and confidence quality; - latency; - cost at production scale; - type and schema guarantees; - data handling and retention; - deployment location; - integration model; - observability; - versioning; - human escalation; - security; - governance evidence. ### Jev and the emergence of System One models TypeSafe AI introduced Jev as its first public System One model and positions it around workflows such as classification, routing, scoring, extraction, verification, guardrails and real-time applications. These are TypeSafe’s descriptions of its model. We cover Jev in more depth elsewhere: - [What Is Jev? System One Models vs LLMs Explained](https://colchix.com/blog/what-is-jev-system-one-model) - [Jev and the EU AI Act](https://colchix.com/blog/jev-eu-ai-act) - [Can European Enterprises Use Jev?](https://colchix.com/blog/can-european-enterprises-use-jev) - [Is There a European Alternative to Jev?](https://colchix.com/blog/european-alternative-to-jev) ### THEMIS and System One² for European enterprise governance Colchix is developing THEMIS, its System One² model focused initially on enterprise AI governance and sensitive-data protection. The intended direction includes: - fast governance decisions; - sensitive-data detection; - runtime controls; - European deployment; - privacy-oriented infrastructure; - integration into Colchix’s governance platform. THEMIS is under development. These are development goals, not generally available capabilities, and THEMIS does not carry any regulatory certification or guarantee of compliance. Read more in [Introducing THEMIS](https://colchix.com/blog/introducing-themis). ### Frequently asked questions #### What is a System One AI model? A System One AI model is a model designed to return fast, structured decisions — such as a category, a score or a yes/no probability — that software can act on directly, rather than generating open-ended text for people to read. #### What is System One AI used for? System One AI is suited to bounded decision tasks inside software: classification, routing, risk scoring, security checks, sensitive-data detection, verification and policy enforcement. #### Is Jev a System One model? Yes. TypeSafe AI introduced Jev in September 2026 and positions it as the first public model explicitly described as a System One model. #### Is System One AI better than an LLM? Not in general. System One models are a different AI primitive for tasks where software needs a bounded decision. LLMs remain better suited to open-ended generation, explanation, conversation and long-form synthesis. Many enterprise systems will use both. #### Can System One AI be used for security? Yes, it can be used as a decision component in security workflows — for example to assess prompts or outputs, detect suspicious interactions or decide whether a request should proceed. Its effectiveness depends on the specific model and how it is evaluated for the task. #### Can System One AI govern AI agents? It can support agent governance by approving or rejecting proposed actions, routing decisions and applying confidence thresholds, with uncertain or sensitive actions escalated to human review. The governance rules themselves still need to be defined and owned by the organisation. #### Can System One models detect sensitive data? A System One model can be used to decide whether content contains personal data, confidential information or credentials, if it has been built and evaluated for that task. Not every System One model automatically provides this capability. #### What is the difference between Jev and THEMIS? Jev is TypeSafe AI’s public System One model. THEMIS is the System One² model Colchix is developing, focused initially on enterprise AI governance and sensitive-data protection for European organisations. THEMIS is under development. ### Sources - [TypeSafe AI — Introducing System One models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [TypeSafe AI documentation — Introduction](https://docs.typesafe.ai/introduction) *Claims about Jev’s performance, speed, cost and calibration are attributed to TypeSafe AI. Colchix is not affiliated with or endorsed by TypeSafe AI.* --- Source: https://colchix.com/blog/system-one-ai-enterprise ## Is There a European Alternative to Jev? System One AI, Sovereignty and THEMIS > Explore European alternatives to Jev, including open decision models, self-hosting and THEMIS, Colchix’s sovereign System One model for Europe. Colchix Team & Gabriele Salvo, CTO · Published 22 September 2026 · Updated 12 October 2026 · System One AI · 9 min read **In short:** There is not yet a widely established, enterprise-supported and EU-sovereign equivalent to Jev. Open-source decision models can be self-hosted in Europe, and conventional classifiers or LLMs can reproduce parts of the workflow. But these options do not automatically provide the complete combination of typed probabilistic decisions, European infrastructure, zero data retention, enterprise deployment and governance controls. Colchix is developing THEMIS to address that gap. [Jev has rapidly drawn attention](https://colchix.com/blog/what-is-jev-system-one-model) to a useful idea: many software systems do not need an AI model to write. They need it to decide. A System One model takes a state, evaluates bounded questions and returns typed answers, probabilities and confidence that software can act on directly. That can make classification, routing, scoring, agent guardrails and policy checks faster and easier to integrate than open-ended text generation. For European enterprises, however, the model interface is only half of the problem. The other half is control: where information is processed, how long it is retained, which legal jurisdiction applies, whether the system can run privately and how every decision is governed and audited. This creates a more specific question than simply asking whether another model can imitate Jev: > **Is there a European System One platform that combines decision intelligence with enterprise sovereignty and governance?** The short answer is: not as a mature, clearly documented category leader yet. ### What would count as a European alternative to Jev? A genuine European alternative should not be defined only by similar API syntax or the ability to return a classification. For enterprise use, it should combine four layers: 1. **Decision capability:** typed choices, scores and binary judgments with useful probabilities or confidence. 2. **European control:** processing, storage, logs and keys within a defined European jurisdiction and infrastructure. 3. **Enterprise deployment:** managed EU cloud, single-tenant, private VPC or on-premises options. 4. **Runtime governance:** policy enforcement, sensitive-data protection, audit evidence and human escalation. | Requirement | Why it matters | | --- | --- | | **Typed decisions** | Software can consume outputs without parsing generated prose. | | **Calibrated uncertainty** | Low-confidence cases can be escalated instead of automated blindly. | | **EU data residency** | Sensitive information remains inside approved European regions. | | **Zero data retention** | Inputs and outputs are not stored beyond the processing required to return a result. | | **Private deployment** | Regulated organisations can control infrastructure and network boundaries. | | **Auditability** | Decisions, confidence and policy outcomes can be reviewed and evidenced. | | **Data protection** | Personal or confidential information can be masked or tokenised before external transmission. | | **Enterprise support** | Security, reliability, contractual and operational requirements can be assessed. | An open model running on a laptop may satisfy local processing. A European-hosted API may satisfy regional data residency. A governance gateway may protect sensitive data. A full alternative must bring those properties together in a deployable enterprise system. ### Option 1: use Jev with a European governance layer The fastest option for many organisations is not to replace Jev, but to control the data sent to it. A European governance layer can sit between an application and the Jev API to: - identify personal, confidential or regulated information; - replace sensitive values with reversible tokens or safe placeholders; - allow, mask, block or escalate each request according to policy; - minimise the context transmitted to the external model; - record the request, decision type, confidence and policy outcome; - preserve evidence for security and compliance review. This architecture can reduce data exposure while allowing a company to use Jev's hosted capabilities. It does not make Jev itself European or sovereign. The underlying model service remains operated by its provider, and any data that is transmitted remains subject to that service's infrastructure, contracts and jurisdiction. This option is most appropriate when an organisation can safely remove sensitive information before processing and does not require the model itself to run inside a European-controlled environment. ### Option 2: self-host an open-source decision model in Europe An emerging open-source ecosystem is reproducing the System One pattern. For example, **Laya** is published as an open-source decision model that accepts state and typed questions and returns choice, score and binary probability outputs. Community projects such as **Arbiter** provide a Jev-compatible serving layer capable of running Laya locally on supported NVIDIA GPUs or Apple Silicon. This creates a practical alternative for technical teams that want: - local inference; - control over the hosting region; - open model weights; - a Jev-compatible request and response shape; - freedom to experiment without sending every input to a third-party API. Self-hosting an open model on European infrastructure can provide data locality. It can also remove the external API from the processing path. But open source is not the same as enterprise readiness. The deploying organisation remains responsible for: - model evaluation and calibration; - security hardening and patching; - availability and scaling; - observability and incident response; - access control and secrets management; - versioning and regression testing; - audit logs and retention; - support, liability and service levels. The open projects are promising, but they should be assessed as rapidly evolving technical components rather than assumed to be drop-in enterprise products. ### Option 3: constrain a conventional LLM into structured output General-purpose LLMs can already classify text, choose from predefined options and return validated JSON. With structured-output or constrained-decoding features, an application can often guarantee that the response matches a schema. A team can also host an open-weight model in Europe and use it as a decision service. This approach offers flexibility and access to a broad model ecosystem. It may be sufficient when: - the decision volume is moderate; - latency is not extremely sensitive; - the task requires some open-ended reasoning; - the organisation already operates an LLM platform; - a single model should handle both decisions and generation. However, a constrained LLM remains a generative model being used for a bounded decision task. It may consume more compute, produce less directly interpretable probabilities and require additional calibration, validation and threshold logic. Structured output solves the shape of the response. It does not automatically solve confidence quality, sovereignty, retention, governance or model-risk management. ### Option 4: use a traditional classifier or rules engine System One tasks existed before the System One label. For stable and narrow use cases, a supervised classifier, rules engine or hybrid decision system may be more appropriate than either Jev or an LLM. Examples include: - classifying a fixed set of support-ticket categories; - detecting known document types; - applying deterministic transaction thresholds; - enforcing explicit security policies; - identifying values that match well-defined patterns. These systems can be fast, inexpensive, explainable and easy to host privately. They are particularly effective when labels are stable and sufficient training data exists. Their limitation is adaptability. A traditional classifier normally requires a defined training and deployment cycle when categories or requirements change. A rules engine handles only the conditions that people explicitly encode. Jev-style models are attractive because they aim to make new semantic judgments from instructions without retraining a separate classifier for every task. ### Comparison: what are the current alternatives? | Approach | Main strength | Main limitation | European sovereignty | | --- | --- | --- | --- | | **Jev with a governance layer** | Immediate access to Jev while reducing sensitive-data exposure | The underlying model remains externally hosted | Partial: governance can be European, model service is not | | **Open decision model such as Laya** | Local inference, open weights and deployment control | Enterprise operations and validation remain the deployer's responsibility | Potentially, when fully hosted and operated in Europe | | **European-hosted open LLM** | Flexible and capable of both reasoning and structured output | Generative architecture may be heavier for bounded decisions | Depends on provider, infrastructure and legal control | | **Traditional classifier** | Fast, efficient and controllable for stable tasks | Usually requires labelled data and retraining | Strong when built and operated within the organisation | | **Rules engine** | Deterministic, transparent and auditable | Cannot make flexible semantic judgments beyond encoded rules | Strong when operated locally | | **[THEMIS](https://colchix.com/blog/introducing-themis)** | Planned combination of System One decisions, European deployment and runtime governance | Currently under development | Designed around European sovereignty | There is therefore no single universal replacement. The best option depends on whether the organisation prioritises speed to deployment, model quality, open weights, operational control, regulatory assurance or integration with an existing AI governance stack. ### Why hosting an open model in Europe is not enough It is tempting to define sovereignty as a server-location problem: deploy open weights on a European cloud and the work is complete. That solves only one layer. A production system must also determine: - whether inputs and outputs are retained; - where logs, backups and encryption keys reside; - who can access the infrastructure; - how model updates are approved; - whether decisions can be reproduced and audited; - how low-confidence outcomes are escalated; - how personal data is minimised; - how organisations prove that policies were enforced. A sovereign model without governance can still make uncontrolled decisions. A governance platform without a sovereign model may still transmit protected data to an external jurisdiction. European enterprise readiness requires both. ### Introducing the direction behind THEMIS Colchix is developing **THEMIS**, its own sovereign, enterprise-ready System One model for real-time data protection and AI governance in Europe. THEMIS begins with a narrow but high-value responsibility: detecting personal and sensitive information and supporting real-time **allow, mask, block or escalate** decisions before data reaches an external AI system. It is being designed to combine: - fast, bounded and machine-readable decisions; - confidence-aware escalation; - European data residency; - zero data retention; - managed EU, single-tenant, private VPC and on-premises deployment paths; - integration with Colchix's runtime masking and governance platform; - audit-ready evidence for every protected interaction. The longer-term direction is broader: a European decision layer that can support general enterprise automation and specialised System One models for regulated use cases. > **Starting with PII. Building Europe's decision layer for enterprise AI.** THEMIS is currently under development. The capabilities above describe the intended product direction, not generally available functionality. Technical specifications, availability and validated benchmark results will be published as development progresses. ### What should European enterprises choose today? For workloads that do not contain sensitive data and do not require European sovereignty, Jev may be evaluated as a hosted decision service. For teams that want control over inference and have the engineering resources to operate the stack, an open decision model hosted in Europe may be worth testing. For stable, narrow problems, a conventional classifier or deterministic rules engine may remain the most reliable choice. For organisations that need the combination of runtime data protection, European deployment, auditability and System One decision intelligence, the category is still emerging. That is the gap THEMIS is intended to address. ### Frequently asked questions #### Is there a European equivalent to Jev? There is not yet a widely established, enterprise-supported and EU-sovereign equivalent with the same combination of typed decisions, European deployment and runtime governance. Open-source decision models can be self-hosted in Europe, while Colchix is developing THEMIS specifically for European enterprise requirements. #### Can Jev be hosted in Europe? TypeSafe's public documentation reviewed for this series does not establish a self-hosted or EU-only Jev deployment. European organisations should confirm any customer-specific regional or private deployment options directly with TypeSafe. #### Is there an open-source alternative to Jev? Yes. Laya is an open-source decision model, and community serving projects such as Arbiter expose a Jev-compatible interface for local inference. These projects should be independently evaluated for accuracy, calibration, security and production readiness. #### Does self-hosting make a model sovereign? Self-hosting can provide infrastructure and data-location control, but sovereignty also depends on operations, access, logging, keys, legal control, dependencies and governance. Hosting location alone is not sufficient. #### Can a European LLM replace Jev? A European-hosted LLM can perform classification and produce structured outputs. It may be suitable for some use cases, but it remains a generative model and may differ in latency, cost, calibration and integration from a purpose-built decision model. #### What is THEMIS? THEMIS is Colchix's sovereign System One model under development for real-time data protection and AI governance in Europe. It begins with PII detection and bounded protection decisions, with a longer-term path toward general and specialised enterprise decision models. ### What Colchix is building Colchix is building **THEMIS**, its own sovereign System One model for real-time data protection and AI governance in Europe. Starting with real-time PII detection and data protection, THEMIS is being designed to give European enterprises the speed and reliability of System One AI with European data residency, zero data retention and flexible deployment. More details about THEMIS will be published as development progresses. ### Sources and disclosure This article is based on TypeSafe AI's official [Jev announcement](https://typesafe.ai/blog/introducing-system-one-models-and-jev), [technical documentation](https://docs.typesafe.ai/introduction), [privacy documentation](https://typesafe.ai/legal/privacy-policy), and the public repositories for [Laya's Node.js implementation](https://github.com/receptron/laya) and the [Arbiter serving layer](https://github.com/0xBakeer/arbiter), reviewed on 23 September 2026. Open-source project capabilities and maturity can change quickly. References to self-hosting or compatibility should not be interpreted as independent certification of security, performance or enterprise readiness. Jev and TypeSafe AI are names belonging to their respective owner. Laya, Arbiter and their associated names belong to their respective maintainers. Colchix is not affiliated with or endorsed by these organisations or projects. This article is for general information and does not constitute legal advice. **Related:** [What Is Jev? System One Models vs LLMs Explained](https://colchix.com/blog/what-is-jev-system-one-model) **Related:** [Can European Enterprises Use Jev? GDPR, Data Residency and EU Readiness Explained](https://colchix.com/blog/can-european-enterprises-use-jev) --- Source: https://colchix.com/blog/european-alternative-to-jev ## Jev and the EU AI Act: What System One Models Mean for AI Governance > How does Jev fit into the EU AI Act? Learn what System One models mean for AI governance, compliance, enterprise deployment and European organisations. Colchix Team & Gabriele Salvo, CTO · Published 22 September 2026 · Updated 12 October 2026 · System One AI · 6 min read Jev is TypeSafe AI’s first System One model: a model designed to return fast, structured decisions rather than generate free-form text. The EU AI Act does not create a special regulatory category for “System One models”, so how Jev or similar models are treated depends on how they are placed on the market, integrated into an AI system and used in practice. The useful distinction is between two different questions. The first is technical: what kind of model is this, and what does it output? The second is legal: what role does each organisation play, and what is the resulting AI system used for? For compliance purposes, the AI Act focuses primarily on the second question: the role of each actor, the intended purpose and how the AI system is used. A model’s architecture tells you how it works, but does not on its own determine which obligations apply. **In short** - Jev is a System One model built for structured decisions rather than text generation. - The AI Act regulates AI based on roles, systems and use cases, not simply whether a model is generative. - A System One model can still sit inside a regulated AI system depending on how it is deployed. - Enterprises therefore still need inventory, risk classification, documentation, monitoring and [governance around System One AI](https://colchix.com/blog/system-one-ai-enterprise). ### What is Jev? Jev was introduced by [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev) in September 2026 and is positioned as the first public System One model. Instead of producing paragraphs of text, Jev takes context or state together with typed questions, and returns structured decisions: a choice from a set of options, a score, or a yes/no probability. It is designed for machine-consumable decisions that software can act on directly. For a fuller introduction, read our explainer on [what Jev is and how System One models differ from LLMs](https://colchix.com/blog/what-is-jev-system-one-model). ### Does the EU AI Act apply to Jev? There is no special “System One model” category in the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj). Whether obligations apply depends on factors such as: - whether the actor is a provider, deployer, importer or distributor; - whether Jev is integrated into a broader AI system; - the intended purpose of that system; - whether the resulting system falls into a regulated or high-risk use case; - which transparency, documentation, risk-management or monitoring duties apply to that particular role and system. The architecture alone does not determine the regulatory outcome. Two organisations using the same model can face very different obligations because they use it for different purposes. When obligations start to apply over time is covered in our [AI Act enforcement timeline](https://colchix.com/blog/ai-act-enforcement-timeline). ### Jev, System One models and general-purpose AI Three concepts are often blurred together, and they should be kept apart: - **A System One model** — a model architecture or category, as described by its developer, that returns structured decisions. - **A general-purpose AI model** — a legal concept defined in the AI Act, with its own criteria. - **An AI system** — an application built using one or more models, which is where most use-case obligations attach. These are not interchangeable. A product label does not decide a legal classification, and a legal classification does not describe how a model works. The European Commission’s [guidelines for providers of general-purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers) focus on the role, capabilities and market placement of general-purpose models. Providers of such models may face documentation, copyright and downstream-information obligations. We are not aware of an authoritative classification of Jev under that regime, and this article does not make one. Whether it falls within the GPAI rules depends on the applicable legal criteria and any authoritative guidance or classification. ### Why System One models still need AI governance Structured output does not remove governance requirements. Organisations using System One AI still need to think about: - AI inventory — knowing which models are in use and where; - approved vs unapproved models; - intended purpose; - risk classification; - data access; - accountability; - monitoring; - auditability; - model changes and versioning; - human oversight where relevant. More deterministic output can make AI easier to integrate into software. But easier integration can also make governance more important, because model decisions can be embedded directly into automated workflows — often with no human reading the output before something happens. ### Where System One models could appear in enterprise AI Decision-oriented models fit naturally into places where software needs a quick, typed answer. Examples include: - routing an AI agent to the next action; - classifying content or requests; - scoring risk or relevance; - deciding whether an action should be escalated; - filtering or gating model interactions; - detecting sensitive information; - policy enforcement; - deciding whether another AI model should be called. In each case, the legal treatment depends on the broader application and its intended purpose — not simply on the fact that a System One model performs the decision. ### System One AI in high-risk use cases If a System One model becomes part of an AI system used in an area classified as high-risk under the AI Act, the broader system may be subject to the relevant high-risk requirements. At a high level, the AI Act lists certain uses involving areas such as: - employment; - essential services; - education; - critical infrastructure; - law enforcement. Not every use in these sectors is automatically high-risk. What matters is the intended purpose of the system and whether it matches a specific classification in the AI Act. This is our reading of how the framework works in general, not a classification of any particular deployment. ### What European enterprises should ask before deploying Jev or another System One model - What decision is the model making? - What system or workflow is it part of? - Who is the provider and who is the deployer? - What data enters the model? - Is personal, confidential or sensitive information involved? - Can the organisation explain and document the model’s role? - What happens when confidence is low? - Is human review required for the use case? - How are versions, policies and configuration changes recorded? - Can the organisation produce evidence of how the model is being used? ### Jev, GDPR and European deployment The EU AI Act does not replace GDPR. Organisations using AI may need to consider both frameworks, depending on the data involved and the use case. Data residency, retention and transfer questions are covered separately in [Can European Enterprises Use Jev? GDPR, Data Residency and EU Readiness](https://colchix.com/blog/can-european-enterprises-use-jev). ### From Jev to sovereign System One AI in Europe Jev has demonstrated interest in a new class of decision-oriented AI models. For European organisations, that raises a further question: where and how such models run. Beyond the AI Act, enterprises may also care about: - European hosting; - data residency; - retention; - control of model infrastructure; - regulated-industry deployment; - private deployment options. We explore the current options in [Is There a European Alternative to Jev? System One AI, Sovereignty and THEMIS](https://colchix.com/blog/european-alternative-to-jev). ### How Colchix approaches System One AI governance Colchix is developing THEMIS, its own enterprise-ready System One² model for European AI governance and data protection use cases. The initial focus is on real-time sensitive-data detection and governance decisions, designed with European deployment and privacy requirements in mind. THEMIS is under development; it is not a direct replacement for Jev in every use case, and it does not carry any regulatory approval or automatic AI Act compliance. Read more in [Introducing THEMIS: Europe’s Enterprise-Ready System One Model for AI Governance](https://colchix.com/blog/introducing-themis). ### Frequently asked questions #### Is Jev compliant with the EU AI Act? There is no simple model-level yes/no answer. Compliance depends on the role of the organisation, how the model is placed on the market or integrated, the intended purpose of the resulting AI system and which AI Act obligations apply. #### Is Jev a general-purpose AI model under the AI Act? We are not aware of any authoritative classification of Jev under the AI Act, so we do not make one. “System One model” is a technical and product category used by TypeSafe AI. It is not the same thing as the AI Act definition of a general-purpose AI model, and the two should not be treated as interchangeable. #### Are System One models covered by the AI Act? Yes, they can fall within the AI Act framework when they are models or components used in AI systems covered by the regulation. There is no separate exemption simply because a model produces structured decisions rather than generated text. #### Can System One models be used in high-risk AI systems? Potentially yes. The classification depends on the intended purpose and the broader system in which the model is used. #### Does using Jev remove GDPR obligations? No. The AI Act and GDPR are separate legal frameworks and may both apply depending on the use case and processing of personal data. #### What is the difference between Jev and THEMIS? Jev is TypeSafe AI’s public System One model. THEMIS is the System One² model Colchix is developing, focused on European enterprise governance and data-protection use cases. THEMIS is under development and is not positioned as a direct replacement for Jev in every use case. ### Sources - [TypeSafe AI — Introducing System One models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [TypeSafe AI documentation — Introduction](https://docs.typesafe.ai/introduction) - [Regulation (EU) 2024/1689 (Artificial Intelligence Act) — EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [European Commission — Guidelines for providers of general-purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers) *This article is general information, not legal advice. Colchix is not affiliated with or endorsed by TypeSafe AI.* --- Source: https://colchix.com/blog/jev-eu-ai-act ## Best Shadow AI Detection Tools in 2026: A Practical Comparison > Compare five shadow AI detection tools for visibility, data protection, audit evidence and European deployment. Find the right platform for your organization. Colchix Team & Gianni Valerio, CEO · Published 20 September 2026 · Updated 12 October 2026 · Shadow AI · 12 min read **In short:** The best shadow AI detection tool depends on the environment you already operate. Colchix is designed for European organizations that want discovery, runtime data protection and audit evidence in one sovereign governance layer. Harmonic Security is a strong purpose-built option for endpoint-level generative AI visibility and inline controls. Netskope and Zscaler suit large enterprises that want shadow AI controls inside an existing SSE or Zero Trust platform. Microsoft Purview is the natural starting point for organizations deeply invested in Microsoft 365, Entra and Copilot. There is no credible universal winner. The right product is the one that can see the AI channels your employees actually use, distinguish approved from unapproved activity, protect sensitive data before disclosure and produce evidence that security, compliance and audit teams can use. This comparison is based on publicly documented product capabilities available on 20 September 2026. It does not claim that every feature was independently tested. Confirm licensing, coverage, deployment and data-residency details with each vendor before purchasing. ### The five shadow AI detection tools at a glance | Platform | Best fit | Publicly documented strengths | Main consideration | | --- | --- | --- | --- | | **Colchix** | European and regulated organizations seeking one governance layer | Shadow AI and AI-powered SaaS discovery, identity exposure mapping, reversible runtime tokenization, EU-only audit evidence | European-first platform focused on integrated discovery, protection and proof | | **Harmonic Security** | Security teams wanting purpose-built GenAI visibility and endpoint controls | Browser and endpoint coverage, personal-account controls, contextual prompt analysis, real-time redaction | Specialist platform; confirm required integrations, geographic hosting and governance workflow fit | | **Netskope Skylight AI Security** | Large organizations already using Netskope One | Discovery across cloud, endpoint and network; unified policy, DLP and agentic AI coverage | Broad enterprise platform that may be heavier than a focused shadow AI project requires | | **Zscaler AI Security** | Enterprises standardizing on Zscaler Zero Trust | AI asset discovery, inline access control, DLP, endpoint and API coverage | Most compelling when Zscaler is already part of the security architecture | | **Microsoft Purview DSPM** | Microsoft-centric organizations governing Copilot and Microsoft data | AI activity insights, sensitivity labels, DLP, audit and data-risk assessments | Third-party AI coverage has prerequisites; value is strongest inside the Microsoft ecosystem | This table is a selection guide, not a laboratory ranking. Product scope changes quickly, and comparable public pricing or standardized detection benchmarks are not available across all five vendors. ### What is a shadow AI detection tool? A shadow AI detection tool identifies AI applications, models, agents or AI-enabled features [used without complete organizational visibility or approval](https://colchix.com/blog/what-is-shadow-ai). A useful platform should show more than a list of visited domains. It should help answer: - Which AI tools and embedded AI features are being used? - Which employees, departments or identities are using them? - Are users signed in with enterprise or personal accounts? - What sensitive data may be entering prompts, uploads or agent workflows? - Which activity violates policy, and what control was applied? - Can the organization produce a defensible audit trail afterward? That distinction matters. A secure web gateway may identify a visit to ChatGPT, but a governance team also needs context: whether the account was approved, whether confidential data was submitted, whether the event was blocked or transformed, and whether the evidence can support an audit or investigation. For a deeper explanation of the visibility problem, read [Shadow AI Detection: How to See What Your Team Actually Uses](https://colchix.com/blog/shadow-ai-detection). ### How we evaluated the tools We assessed the vendors against seven practical questions. These criteria are more useful than counting the number of AI domains in a catalogue. 1. **Discovery coverage:** Can the platform find direct LLM use, AI-enabled SaaS, endpoints, APIs, agents or other relevant channels? 2. **Identity context:** Can it connect activity to users and distinguish enterprise access from personal accounts? 3. **Data visibility:** Can it identify sensitive information in prompts, files or AI interactions? 4. **Runtime control:** Can it warn, block, redact or otherwise protect data before it reaches an external AI service? 5. **Governance evidence:** Does it retain useful records for investigations, policy review and audits? 6. **European operating fit:** Can deployment, data handling and evidence requirements be aligned with EU organizations? 7. **Operational fit:** Does the product match the buyer's existing security stack, skills and rollout capacity? The assessment uses vendor documentation, not undisclosed product testing. Where a capability is not clearly documented, we do not assume it exists. ### 1. Colchix: best for sovereign European AI governance **Best for:** European organizations that want shadow AI discovery to connect directly with runtime protection and audit-ready evidence. Colchix is an all-in-one AI governance platform for European enterprises. [ARGUS](https://colchix.com/agents/argus) identifies direct LLM use, AI-powered SaaS, OAuth exposure and personal-account access. [TALOS](https://colchix.com/agents/talos) protects sensitive information with reversible tokenization before data reaches an external model. [ATHENA](https://colchix.com/agents/athena) turns governed interactions into compliance and audit records. The important distinction is scope. Colchix does not present discovery as an isolated dashboard. Its intended workflow is to move from **what AI is in use**, to **what sensitive data is exposed**, to **what technical protection was applied**, to **what evidence can be produced**. #### Where Colchix stands out - Built around European data control and EU-only infrastructure. - Covers direct LLMs and AI capabilities embedded in SaaS, rather than treating AI as a fixed domain list. - Maps AI usage to identities, departments, account types and risk levels. - Connects visibility with reversible tokenization instead of relying only on destructive redaction or blanket blocking. - Produces governance records through the same runtime control layer. #### What to verify Buyers should validate connector coverage, endpoint support and deployment options against their exact environment. Organizations should also determine whether they need a focused AI governance control plane or a broader replacement for their existing SASE and network security stack. **Bottom line:** Put Colchix on the shortlist when European control, cross-tool visibility, runtime data protection and auditability are core requirements. [Explore Colchix's approach to shadow AI governance](https://colchix.com/#platform) ### 2. Harmonic Security: best purpose-built option for endpoint GenAI control **Best for:** Security teams that want rapid visibility into employee use of generative AI and contextual controls close to the user. Harmonic Security positions itself as a specialist AI governance and control layer. Its public documentation describes endpoint-based analysis of prompts, real-time redaction, classification of AI services and controls for employees using personal versions of tools such as ChatGPT or Claude. It supports major browsers and can be deployed using common device-management tools. Harmonic's use of small language models to assess prompt context is particularly relevant where traditional regex-based DLP produces too many false positives. Its product story is focused on allowing useful AI activity while controlling sensitive submissions. #### Where Harmonic stands out - Purpose-built for workforce use of generative AI. - Strong public emphasis on personal-account detection and control. - Contextual analysis of unstructured prompts and sensitive business information. - Inline redaction and policy enforcement at the endpoint. - Broad browser support documented by the vendor. #### What to verify Confirm how coverage extends beyond supported endpoint and browser paths in your environment, how evidence integrates with existing governance processes, and which hosting or residency options apply to the proposed deployment. Ask for a proof of coverage against your real AI application inventory. **Bottom line:** Harmonic is a strong shortlist candidate for organizations prioritizing endpoint-level GenAI visibility and precise inline DLP without first replacing their broader network security stack. Source: [Harmonic Security — DLP for GenAI](https://www.harmonic.security/solutions/dlp-for-genai). ### 3. Netskope Skylight AI Security: best for Netskope-centered enterprises **Best for:** Large enterprises that already use Netskope One or want shadow, enterprise and agentic AI governed through a broad SSE platform. Netskope describes Skylight AI Security as a unified layer for shadow consumer AI, enterprise public AI, private AI and agentic AI. Its documented discovery spans cloud, endpoint and network activity, with a common policy engine and data security controls. Runtime protections include redaction and blocking before sensitive information reaches a model. For an existing Netskope customer, that breadth can reduce the need to operate a separate visibility tool. The platform can place AI activity in the same operational context as web, cloud and enterprise data controls. #### Where Netskope stands out - Continuous inventory across users, applications, agents, models and AI interactions. - Cloud, endpoint and network visibility in one platform. - Integrated data security, policy enforcement and runtime controls. - Coverage designed to include shadow AI and agentic AI use cases. - Strong fit with an established Netskope One deployment. #### What to verify Clarify which modules and licences are required for the desired discovery and enforcement paths. Validate endpoint, API, agent and unmanaged-device coverage in your own architecture. Organizations seeking only a focused shadow AI project should also compare deployment effort and total scope with specialist platforms. **Bottom line:** Netskope is most attractive when the organization wants AI controls as part of a wider SSE and data security strategy, especially if Netskope One is already deployed. Source: [Netskope — AI Security](https://www.netskope.com/products/ai-security). ### 4. Zscaler AI Security: best for Zscaler Zero Trust environments **Best for:** Global enterprises that already route workforce and application traffic through Zscaler and want to extend that control plane to AI. Zscaler's current AI Security portfolio combines AI asset management, secure access, endpoint protection and an AI gateway. The vendor documents discovery of models, agents, MCP servers and shadow AI, together with role-based access, sensitive-data filtering and inline DLP for models, agents and API calls. This is broader than a standalone discovery product. It is designed to govern the path between users, devices, applications, agents and AI services within the Zscaler architecture. #### Where Zscaler stands out - AI asset discovery tied to a large Zero Trust platform. - Documented coverage across users, endpoints, APIs, agents and MCP servers. - Role-based access control and filtering of sensitive data. - Inline AI gateway capabilities for model, agent and API traffic. - Natural operational fit for existing Zscaler customers. #### What to verify Determine which products and traffic paths are necessary for complete visibility in your environment. Check whether the organization needs the broader platform scope and assess how AI governance evidence will map to legal, privacy and audit workflows—not only security operations. **Bottom line:** Zscaler belongs on the shortlist for enterprises already committed to its Zero Trust Exchange or seeking a wide AI security architecture. A smaller organization may find a dedicated product easier to pilot. Source: [Zscaler — AI Security](https://www.zscaler.com/products-and-solutions/ai-security). ### 5. Microsoft Purview DSPM for AI: best for Microsoft-first organizations **Best for:** Organizations whose AI adoption, identities and sensitive information are concentrated in Microsoft 365, Entra, SharePoint, Copilot and related services. Microsoft Purview Data Security Posture Management provides a central location for AI activity insights, data-risk assessments and policies designed to protect information used by Copilots, agents and third-party AI applications. Microsoft documents support for DLP in AI prompts, sensitivity labels, audit events and activity details including user, application, time and detected sensitive information. Its strategic advantage is context. A Microsoft-centric organization may already have identity, information-protection and compliance signals that Purview can apply to AI governance. #### Where Microsoft Purview stands out - Deep connection to Microsoft 365, Entra, Copilot and Microsoft information protection. - AI activity reports and detailed activity exploration. - Data-risk assessments for oversharing in Microsoft repositories. - DLP, sensitivity labels and compliance controls within the same ecosystem. - Documented support for selected third-party generative AI sites. #### What to verify Microsoft states that third-party AI site coverage requires prerequisites such as device onboarding and the Purview browser extension. Confirm the supported site list, licensing, policy dependencies and coverage of non-Microsoft endpoints, desktop applications, APIs and embedded AI. Also note that Microsoft has replaced the classic DSPM for AI experience with a broader current version, so procurement should be based on the latest documentation. **Bottom line:** Purview is a logical first evaluation for Microsoft-heavy estates. It should not automatically be assumed to provide complete visibility across every non-Microsoft AI channel. Source: [Microsoft Learn — Data Security Posture Management for AI](https://learn.microsoft.com/en-us/purview/dspm-for-ai). ### Which shadow AI detection tool should you choose? Use the decision rule below as a starting point: - **Choose Colchix** if EU sovereignty, runtime data protection and audit evidence must operate as one governance system. - **Choose Harmonic Security** if your immediate priority is purpose-built workforce GenAI visibility and contextual endpoint controls. - **Choose Netskope** if your organization already uses Netskope One or wants AI governance inside a broad SSE and data security platform. - **Choose Zscaler** if Zscaler is already your strategic Zero Trust layer and you need coverage extending into endpoints, APIs and agents. - **Choose Microsoft Purview** if Microsoft 365, Copilot, Entra and Microsoft information protection contain most of your users and sensitive data. The shortlist should follow the architecture, not the logo. Two organizations with the same headcount may need different products because one routes traffic through an SSE platform while the other depends on unmanaged browsers, personal AI accounts and embedded AI features. ### Questions to ask every vendor during a proof of concept A product demonstration is not enough. Test each platform against real workflows and ask for observable evidence. 1. Can you detect AI used through personal as well as enterprise accounts? 2. Can you identify AI inside SaaS products, browser extensions, desktop applications, APIs and agents—not only visits to known AI websites? 3. Which operating systems, browsers and unmanaged-device scenarios are supported? 4. Can you show the user, department, account type, tool, timestamp and policy outcome for an event? 5. What happens to sensitive data: monitor, warn, block, redact or tokenize? 6. Where are prompts, classifications, logs and encryption keys processed and stored? 7. Can administrators minimize or mask prompt content while retaining useful evidence? 8. How are new AI tools and domains discovered and classified? 9. Can evidence be exported for a DPO, regulator, internal audit or incident investigation? 10. Which capabilities require separate licences, agents, gateways, extensions or integrations? Run the same scenarios for every shortlisted vendor. Include an approved enterprise LLM, a personal account, a lesser-known AI tool, an AI feature embedded in SaaS, a file upload and a prompt containing synthetic sensitive data. Never use real confidential information in a product trial. ### Detection alone is not governance A dashboard that lists AI applications answers only the first question. Operational governance requires a closed loop: 1. **Discover** the tool, identity and usage path. 2. **Classify** the risk and applicable policy. 3. **Protect** sensitive data at the moment of use. 4. **Record** what happened and which control was applied. 5. **Review** the evidence and improve policy. This is why domain discovery alone is insufficient. It can show that an employee accessed an AI service, but not necessarily what account was used, what data was submitted or whether an AI feature inside another application processed company information. For the control layer behind this process, see [Runtime AI Governance: Why Policy Alone Is Not Enough](https://colchix.com/blog/runtime-ai-governance). ### Final verdict The best shadow AI detection tool in 2026 is the one that covers your real usage paths and turns visibility into enforceable, reviewable governance. Colchix is the European-first option for organizations seeking a sovereign combination of shadow AI discovery, reversible runtime protection and audit evidence in one platform. Harmonic offers a focused approach to employee GenAI usage and endpoint controls. Netskope and Zscaler provide wide coverage inside broad enterprise security platforms. Microsoft Purview offers valuable depth where Microsoft identities, data and Copilot dominate. Do not buy from a feature matrix alone. Build an inventory of actual AI usage, define the evidence your DPO and auditors require, then run a controlled proof of concept against the blind spots that matter most. ### Frequently asked questions #### What is the best shadow AI detection tool in 2026? There is no universal best product. Colchix fits European organizations seeking sovereign discovery, runtime protection and audit evidence; Harmonic is strong for purpose-built endpoint GenAI controls; Netskope and Zscaler suit enterprises using their wider security platforms; Microsoft Purview fits Microsoft-centric environments. #### Can a CASB or secure web gateway detect shadow AI? It can detect many visits and data flows to known AI services, especially when traffic passes through the managed control point. Coverage may be incomplete for personal accounts, encrypted or unmanaged paths, desktop tools, APIs, agents and AI embedded inside other SaaS products. Test the exact channels used by your workforce. #### What is the difference between shadow AI discovery and AI DLP? Shadow AI discovery identifies which AI services or features are in use and by whom. AI DLP examines or controls the information sent to those services. Effective governance normally needs both: discovery without protection leaves risk untreated, while protection without broad discovery leaves blind spots. #### Can shadow AI tools detect personal ChatGPT or Claude accounts? Some can, but the answer depends on the product and access path. Harmonic and Colchix publicly describe personal-account visibility or controls. Buyers should validate account-level detection in their own browsers, devices and identity architecture during a proof of concept. #### What should European companies check before buying? Check where prompts, metadata, logs and keys are processed; which subprocessors are involved; how retention and access are controlled; whether data minimization is supported; and whether the platform produces evidence relevant to GDPR, the EU AI Act and internal governance. EU hosting alone does not answer all of these questions. #### How long does a shadow AI proof of concept take? The duration depends on deployment and scope. A useful pilot should last long enough to capture representative behavior across departments, devices and AI channels. Define success criteria in advance: detection coverage, false positives, policy latency, user impact, evidence quality and operational effort. --- Source: https://colchix.com/blog/best-shadow-ai-detection-tools-2026 ## Can European Enterprises Use Jev? GDPR, Data Residency and EU Readiness Explained > Can Jev be used in Europe? Assess its GDPR, data residency, retention, deployment and sovereignty considerations for European enterprises. Colchix Team & Gabriele Salvo, CTO · Published 20 September 2026 · Updated 12 October 2026 · System One AI · 9 min read **In short:** Yes, European enterprises can use Jev, but using it lawfully is not the same as deploying a sovereign European AI system. TypeSafe provides contractual GDPR mechanisms and says customer inputs are not used to train its models. However, its public privacy documentation states that the service is hosted in the United States, and its standard terms do not promise EU-only processing or zero data retention. For European technology and procurement teams, that distinction matters. Jev is TypeSafe AI’s first System One model: a model designed to make fast, typed decisions that software can consume directly. Its architecture may be attractive for classification, routing, scoring, policy checks and agent guardrails. But model performance is only one part of enterprise readiness. Before sending personal data, confidential records or regulated information to any external AI service, European organisations must also understand where the data is processed, how long it is retained, which subprocessors can access it, what contractual safeguards apply and whether the deployment fits their own risk requirements. This article assesses Jev against those questions using TypeSafe’s publicly available documentation, most recently reviewed on 23 September 2026. ### The short answer: can Jev be used in Europe? There is no general rule that prevents a European company from using a US AI provider. A European organisation can use Jev if it has an appropriate lawful basis, conducts the necessary vendor and transfer assessments, enters into the required contractual arrangements and configures the service consistently with its GDPR obligations. TypeSafe publishes a Data Processing Addendum and incorporates the European Commission’s Standard Contractual Clauses for transfers of personal data from the European Union. Its privacy policy also states that customer input is not used to train or fine-tune its AI models. Those are meaningful enterprise controls. However, TypeSafe’s privacy policy states that its services are hosted in the United States and that users from the EEA transfer personal data to the US for storage and processing. The public documents reviewed for this article do not promise EU-only data residency, customer-selectable European inference, on-premises deployment or zero data retention. The accurate conclusion is therefore: > **Jev can be evaluated and used by European organisations, but its standard public offering should not be described as EU-sovereign.** Whether it is appropriate for a particular workload depends on the data involved, the organisation’s risk tolerance and the contractual and technical controls available to that customer. ### What does “European-ready” mean for an AI model? “Available in Europe,” “GDPR-capable” and “European sovereign” describe different things. | Requirement | What it means | | --- | --- | | **Available in Europe** | European customers are allowed to access and purchase the service. | | **GDPR-capable** | The provider supplies mechanisms such as a DPA, processor commitments and safeguards for international transfers. | | **EU data residency** | Customer data is stored and processed within specified European regions. | | **Zero data retention** | Prompts and outputs are not retained after the processing required to return the result, subject to precisely defined exceptions. | | **European sovereignty** | Data, infrastructure, operational control and legal exposure remain within a European jurisdiction and control framework. | | **Enterprise-ready** | The service also meets the organisation’s security, reliability, access-control, audit, support and deployment requirements. | A provider may satisfy some of these requirements without satisfying all of them. A DPA can support GDPR compliance while the underlying processing still takes place in the United States. Similarly, EU-hosted infrastructure does not automatically create sovereignty if control, keys, support access or legal jurisdiction remain outside Europe. ### What TypeSafe publicly provides TypeSafe has already published several elements that European procurement teams would expect from an enterprise AI vendor. #### A Data Processing Addendum TypeSafe’s DPA identifies the customer as controller and TypeSafe as processor when TypeSafe processes customer personal data. It commits TypeSafe to process that data according to documented instructions and applicable data-protection obligations. #### Standard Contractual Clauses For transfers from the European Union, the DPA incorporates the European Commission’s Standard Contractual Clauses. It specifies the controller-to-processor module and, where relevant, the processor-to-subprocessor module. SCCs are a recognised legal transfer mechanism. They do not create EU data residency: they are safeguards for transferring data outside the EEA. #### No model training on customer input TypeSafe’s privacy policy states that it will not train or fine-tune AI or machine-learning models on customer input. Its Master Customer Agreement similarly says customer data will not be included in a model-training dataset without the customer’s prior consent. This is an important distinction for enterprises concerned about confidential data being reused to improve a shared model. #### Subprocessor and security commitments The DPA refers customers to TypeSafe’s Trust Center for its subprocessor list and security safeguards. It also provides advance notice of new subprocessors and allows customers to object on reasonable privacy or security grounds. The DPA includes incident-notification commitments and a limited right to audit TypeSafe’s controls, subject to the conditions stated in the agreement. These provisions make Jev more assessable for enterprise buyers. They should be reviewed together with the current Trust Center, order form and any customer-specific commercial terms. ### Where the European sovereignty gap remains The existence of a DPA does not answer every operational question. #### The public service is hosted in the United States TypeSafe’s privacy policy states that the services are hosted in the US. For EEA users, personal data is transferred outside Europe for storage and processing. That does not automatically make the service unlawful. It does mean that organisations seeking EU-only processing or a sovereign European deployment need additional options that are not established in the public documents reviewed here. #### Retention is not presented as zero TypeSafe’s DPA says customer personal data is retained for as long as necessary in light of the purpose of processing and applicable law. Its Master Customer Agreement also permits certain processing of customer data for service delivery, billing, fraud prevention, legal compliance and the generation of telemetry. This is not the same as a clearly defined zero-data-retention commitment for prompts and outputs. An enterprise should therefore ask for the exact retention period for inputs, outputs, logs, backups and telemetry; the deletion process; and whether a stricter retention configuration is available contractually. #### EU-only deployment is not publicly documented The public materials reviewed for this article do not describe a customer-selectable EU inference region, a European private cloud deployment, a private VPC option or an on-premises version of Jev. TypeSafe may offer customer-specific arrangements that are not public. Procurement teams should confirm them directly rather than assume that they exist. #### A US company remains subject to US jurisdiction TypeSafe AI, Inc. is a US company, and its standard customer agreement is governed by California and US law. European organisations with strict sovereignty requirements may therefore consider not only where a server is located, but also which entity operates the service and which legal regimes can reach the provider. ### Jev enterprise-readiness checklist for European buyers Before deploying Jev with production data, a European enterprise should obtain clear answers to the following questions. | Area | Question to verify | | --- | --- | | **Data location** | In which countries are inputs, outputs, logs, backups and telemetry processed and stored? | | **Retention** | What is retained, for how long, and can zero retention be enforced contractually and technically? | | **Training** | Are inputs or outputs used for training, fine-tuning, evaluation or human review? | | **Transfers** | Which transfer mechanism applies, and has the organisation completed its transfer assessment? | | **Subprocessors** | Which infrastructure, security and support providers can access customer data? | | **Deployment** | Are EU region, single-tenant, private VPC or on-premises options available? | | **Security** | Which certifications, penetration tests, encryption controls and incident procedures can be evidenced? | | **Access control** | Are SSO, role-based permissions, service accounts and key rotation supported? | | **Auditability** | Can the organisation export decision logs, confidence values, policy outcomes and evidence? | | **Model risk** | How are accuracy, calibration, drift, failure modes and human escalation tested for the intended use case? | The answer may differ by workload. Routing an anonymous support request is not equivalent to processing patient data, employee records, financial information or customer identifiers. ### GDPR compliance is not a feature a vendor can grant No AI vendor can make a customer “GDPR compliant” merely by offering a DPA. The customer remains responsible for questions such as: - the lawful basis for processing; - transparency to data subjects; - data minimisation and purpose limitation; - access controls and retention policies; - the need for a Data Protection Impact Assessment; - international transfer risk; - human oversight and contestability where decisions affect individuals. Jev’s typed outputs and confidence estimates may make certain decisions easier to test and audit than free-form generated text. But structured output does not remove the legal and organisational obligations attached to the underlying data and use case. ### Can Jev be made safer for European enterprise use? Yes. An organisation can reduce exposure by controlling what reaches the model. One architecture is to place a governance layer before the external API: 1. detect personal, confidential or regulated information before transmission; 2. replace sensitive values with reversible tokens or safe placeholders; 3. send only the minimum necessary context to the model; 4. restore authorised values locally when required; 5. log the policy decision, model response and confidence for audit; 6. block or escalate requests that cannot be processed safely. This approach does not change the provider’s jurisdiction, but it can substantially reduce the amount of sensitive information exposed to an external service. For some workloads, that may make a US-hosted model acceptable. For organisations requiring EU-only processing and control, the model itself must also be available inside an appropriate European deployment. ### Why Colchix is building THEMIS Jev demonstrates the value of fast, typed decisions for software. Colchix is developing **[THEMIS](https://colchix.com/blog/introducing-themis)** to bring that model category to European enterprise data protection and AI governance. THEMIS begins with real-time detection of personal and sensitive information and bounded **allow, mask, block or escalate** decisions before data reaches an external AI system. It is being designed around European data residency, zero data retention and flexible deployment, with a longer-term path toward a broader European System One model and specialised decision models for regulated use cases. > **Starting with PII. Building Europe’s decision layer for enterprise AI.** THEMIS is currently under development. Deployment characteristics and performance objectives should be treated as product direction until Colchix publishes validated technical documentation and benchmark results. ### Frequently asked questions #### Can Jev legally be used in the European Union? Yes, potentially. European organisations can use US-hosted AI services when they establish a lawful basis, meet their GDPR obligations and implement an appropriate mechanism for international data transfers. Suitability must be assessed for the specific data and use case. #### Is Jev GDPR compliant? GDPR compliance applies to a processing activity, not to a model in isolation. TypeSafe publishes a DPA and incorporates EU Standard Contractual Clauses, but each customer must assess its own lawful basis, data flows, risks and controls. #### Is Jev hosted in Europe? TypeSafe’s public privacy policy states that its services are hosted in the United States. The public documents reviewed for this article do not establish an EU-only inference or storage option. #### Does TypeSafe train Jev on customer data? TypeSafe’s privacy policy states that it does not train or fine-tune AI or machine-learning models on customer input. Its customer agreement also says customer data will not be included in a training dataset without prior consent. #### Does Jev offer zero data retention? The standard public documents reviewed for this article do not provide a clear zero-data-retention commitment for Jev inputs and outputs. Enterprises should confirm exact retention periods and any customer-specific zero-retention option directly with TypeSafe. #### Is there a sovereign European alternative to Jev? Colchix is developing THEMIS, its own sovereign, enterprise-ready System One model for real-time data protection and AI governance in Europe. It begins with PII detection and real-time protection decisions and is currently under development. ### What Colchix is building Colchix is developing **THEMIS**, its own sovereign System One model for real-time data protection and AI governance in Europe. Starting with real-time PII detection and data protection, THEMIS is being designed to give European enterprises the speed and reliability of System One AI with European data residency, zero data retention and flexible deployment. More details about THEMIS will be published as development progresses. ### Sources and disclosure This article is based on TypeSafe AI’s publicly available [Master Customer Agreement](https://typesafe.ai/legal/mca), [Data Processing Addendum](https://typesafe.ai/legal/data-processing), [Privacy Policy](https://typesafe.ai/legal/privacy-policy), [Jev documentation](https://docs.typesafe.ai/introduction) and [Jev announcement](https://typesafe.ai/blog/introducing-system-one-models-and-jev), reviewed on 23 September 2026. The article distinguishes between commitments stated in public documents and capabilities that were not publicly documented at the time of review. Absence from public documentation does not prove that a customer-specific option is unavailable. Jev and TypeSafe AI are names belonging to their respective owner. Colchix is not affiliated with or endorsed by TypeSafe AI. This article is for general information and does not constitute legal advice. Organisations should verify current terms directly with the provider and obtain professional advice for their own processing activities. **Related:** [What Is Jev? System One Models vs LLMs Explained](https://colchix.com/blog/what-is-jev-system-one-model) --- Source: https://colchix.com/blog/can-european-enterprises-use-jev ## What Is Jev? System One Models vs LLMs Explained > Jev is TypeSafe AI's first System One model. Learn how it differs from LLMs, how typed probabilistic decisions work, and where it fits in enterprise AI. Colchix Team & Gabriele Salvo, CTO · Published 15 September 2026 · Updated 12 October 2026 · System One AI · 7 min read **In short:** Jev is TypeSafe AI's first System One model: an AI model designed to return fast, typed and probabilistic decisions that software can use directly, rather than generating text for a person to read. That distinction matters. Large language models such as ChatGPT, Claude and Gemini are exceptionally flexible, but many enterprise workflows do not need another paragraph of generated text. They need a decision: approve or escalate, select a route, assign a risk score, identify the best next action or determine whether a policy condition is true. Jev represents a new approach to those problems. Instead of asking a general-purpose language model to generate an answer and then parsing that answer back into software, a System One model produces a structured result from the beginning. This guide explains what Jev is, how System One models work, how they differ from LLMs and why the category could become important for [enterprise automation and AI governance](https://colchix.com/blog/system-one-ai-enterprise). ### The short answer: what is Jev? Jev is a proprietary AI model developed by TypeSafe AI and introduced in September 2026. TypeSafe describes it as the first **System One model**, a category built for fast, structured decisions inside software. A Jev request contains: - a **state**: the information or situation the model must evaluate; - one or more **typed questions**: the specific decisions the application needs; - predefined output structures that the surrounding code can use directly. Instead of returning prose, Jev returns typed values, probability distributions and, for certain question types, confidence scores. TypeSafe currently exposes three primitives: | Primitive | Purpose | Example output | | --- | --- | --- | | **Choice** | Select from predefined options | Route A, B or C, with probabilities and confidence | | **Score** | Evaluate against an ordered rubric | Low, medium or high risk, with a continuous score | | **Noul** | Determine whether a statement is true | A probability between 0 and 1 | Multiple questions can be evaluated independently and in parallel against the same state. This makes the model suitable for applications that need several related judgments without generating a separate response for each one. ### What is a System One model? The name comes from the distinction between fast, intuitive **System 1** thinking and slower, deliberate **System 2** reasoning popularised by Daniel Kahneman. In practical software terms: - **System One AI** is designed for rapid, bounded judgments; - **LLMs and reasoning models** are better suited to open-ended generation, explanation and multi-step reasoning. A System One model does not try to write the perfect answer to an unrestricted question. It evaluates a defined state and returns decisions within a structure established by the developer. TypeSafe describes the ideal question as a focused judgment that a knowledgeable person could make quickly if given the right context. More complex decisions should be decomposed into smaller questions and combined through deterministic code. For example, instead of asking: > Should this transaction be approved? an application might ask separately: - Does the transaction match the customer's normal behaviour? - Is the destination considered high risk? - Does the amount exceed the applicable threshold? - Is the available evidence sufficient for automatic approval? The application can then combine those probabilities with its own policies, thresholds and escalation rules. ### Jev vs LLMs: what is the difference? Jev is not intended to replace ChatGPT, Claude, Gemini or other general-purpose LLMs. It addresses a different part of the AI stack. | Dimension | Jev / System One model | Traditional LLM | | --- | --- | --- | | Primary purpose | Structured decisions | Text generation and reasoning | | Output | Typed values and probabilities | Natural-language strings or generated structured output | | Possible answers | Defined in advance | Open-ended | | Execution | Questions evaluated in parallel | Tokens generated sequentially | | Best suited to | Classification, routing, scoring, policy checks | Writing, conversation, synthesis, coding, complex reasoning | | Software integration | Directly consumed by code | Often requires parsing and validation | | Confidence | Built into supported decision types | Usually prompted or estimated separately | An LLM can still perform classification and return structured JSON. The difference is architectural: an LLM remains a text-generation system being constrained into a decision-shaped response, while Jev is designed and trained for structured probabilistic decisions. ### Does Jev hallucinate? TypeSafe says Jev cannot produce type errors because the set and structure of valid outputs are defined in advance. It cannot unexpectedly return a poem, malformed tool call or unparseable paragraph when the application expects a predefined choice. That does **not** mean every decision must be factually or semantically correct. A model can return a perfectly valid structured output and still choose the wrong option. The practical advantage is that the uncertainty is exposed through probabilities and confidence, allowing developers to set thresholds, request human review or invoke a more capable reasoning model when confidence is insufficient. For enterprise teams, the useful distinction is therefore: > Jev is designed to eliminate unbounded output and schema errors, while calibrated confidence helps applications manage the remaining risk of an incorrect judgment. ### What is Jev good for? System One models are most compelling when an application repeatedly makes bounded decisions at high volume. #### Classification and routing Jev can classify a support request, identify intent, estimate urgency and select the appropriate queue. The surrounding software remains responsible for executing the route. #### AI agent guardrails Before an agent calls a tool, modifies data or executes code, a System One model can evaluate whether the proposed action appears risky, irreversible or outside policy. #### Model routing An application can decide whether a request requires a fast low-cost model, a more capable reasoning model or human review. #### Risk and policy decisions Rather than asking an LLM to write a compliance assessment, an application can request a set of specific risk determinations and combine them with deterministic policy logic. #### Real-time applications TypeSafe reports end-to-end response times between approximately 70 and 500 milliseconds for its service, depending on the workload. This makes the category relevant where a conventional reasoning call would introduce unacceptable latency. These figures are TypeSafe's own published results and should be independently validated for each production use case. #### Data protection and AI governance A System One model can evaluate whether a prompt contains sensitive information, whether a destination is approved, whether masking would destroy the meaning of a request and whether an interaction should be allowed, protected, blocked or escalated. This is particularly relevant to runtime AI governance, where decisions must happen before information reaches an external model. ### When should enterprises still use an LLM? Use an LLM when the desired output is language or when the problem requires open-ended reasoning. Examples include: - drafting an email or report; - summarising a long document; - answering conversational questions; - producing or reviewing code; - explaining the reasons behind a complex conclusion; - solving a task whose possible answers cannot be defined in advance. In many systems, the strongest architecture may combine both categories: 1. a System One model rapidly classifies the situation and selects the next action; 2. deterministic code applies policies and thresholds; 3. an LLM handles open-ended reasoning or generation only when required; 4. low-confidence or high-impact cases are sent to a human. The opportunity is not **Jev versus LLMs**. It is using each model class for the work it is best designed to perform. ### Why System One models matter for enterprise AI Enterprise automation needs more than model intelligence. It needs predictable interfaces, bounded behaviour, measurable uncertainty, low latency and the ability to connect AI judgments to ordinary software controls. System One models could help close the gap between impressive AI demonstrations and production workflows by making AI decisions easier to: - consume programmatically; - test against defined evaluation sets; - route according to confidence; - combine with deterministic policies; - log and audit; - monitor over time. However, model behaviour is only one part of enterprise readiness. Organisations must also evaluate security, privacy, data residency, retention, contractual protections, access controls, deployment options, monitoring and regulatory obligations. For European organisations, those operational and jurisdictional questions are especially important when prompts may contain personal data, confidential information or regulated records. ### What Colchix is building with THEMIS Jev has demonstrated the potential of a new model category. Colchix is now developing **[THEMIS](https://colchix.com/blog/introducing-themis)**, a sovereign, enterprise-ready System One model for real-time data protection and AI governance in Europe. THEMIS is starting with a focused use case: identifying personal and sensitive information and supporting real-time **allow, mask, block or escalate** decisions before data reaches an external AI system. The longer-term vision is to expand from PII protection into a general-purpose European decision model and specialised models for regulated enterprise workflows. > **Starting with PII. Building Europe's decision layer for enterprise AI.** THEMIS is currently under development. Any performance objectives published by Colchix should be treated as development targets until validated benchmark results are released. ### Frequently asked questions #### Is Jev an LLM? Jev is built from transformer-model technology, but it is not a conventional generative LLM product. It does not produce open-ended text. It evaluates state against typed questions and returns structured decisions, probabilities and confidence. #### Is Jev open source? No. Jev is a proprietary model offered by TypeSafe AI. TypeSafe has published open-source tooling that helps conventional LLMs use a compatible System One-style interface, but that tooling is not the Jev model itself. #### Does Jev replace ChatGPT or Claude? No. Jev is designed for bounded decisions such as classification, routing and scoring. Chat-oriented LLMs remain more appropriate for generation, conversation and complex reasoning. #### Can a System One model make an incorrect decision? Yes. A typed output can still be semantically incorrect. The benefit is that the possible outputs are constrained and supported decision types expose probabilities or confidence that applications can use for escalation and review. #### What are the main Jev use cases? The main use cases include classification, routing, scoring, agent guardrails, model selection, workflow branching and other high-volume decisions with predefined outputs. #### Is there a European System One model? Colchix is developing THEMIS, a sovereign, enterprise-ready System One model designed for European organisations. It begins with real-time PII detection and data protection, with a roadmap toward broader and industry-specific enterprise decision models. THEMIS is currently under development. > Colchix is building THEMIS, its own sovereign, enterprise-ready System One model for real-time data protection and AI governance in Europe. > > Starting with real-time PII detection and data protection, THEMIS is being developed to give European enterprises the speed and reliability of System One AI with European data residency, zero data retention and flexible deployment. ### Sources and disclosure This article is based primarily on TypeSafe AI's official [Jev announcement](https://typesafe.ai/blog/introducing-system-one-models-and-jev) and [technical documentation](https://docs.typesafe.ai/introduction), accessed on 23 September 2026. Jev and TypeSafe AI are names belonging to their respective owner. Colchix is not affiliated with or endorsed by TypeSafe AI. Product capabilities, availability and commercial terms may change; readers should verify current information directly with the provider. --- Source: https://colchix.com/blog/what-is-jev-system-one-model ## Best AI Governance Platforms for European Enterprises in 2026 > Compare six AI governance platforms for European enterprises across discovery, risk, runtime controls, audit evidence and regulatory alignment. Colchix Team & Gianni Valerio, CEO · Published 5 September 2026 · Updated 12 October 2026 · AI Governance · 13 min read **In short:** Colchix is designed for European enterprises that want AI discovery, runtime data protection and audit evidence in one sovereign governance layer. Credo AI is a strong purpose-built choice for policy, risk and regulatory governance. Holistic AI combines AI inventory with model testing and continuous compliance. IBM watsonx.governance suits large organisations governing AI across complex model and GRC environments. OneTrust connects AI governance with privacy, risk workflows and runtime controls. ServiceNow AI Control Tower fits enterprises that want AI governance tied to their existing CMDB and ServiceNow workflows. There is no single best platform for every organisation. The right choice depends on what must be governed: employee use of external AI, internally developed models, third-party AI vendors, autonomous agents, sensitive data flows, regulatory obligations—or all of them together. > **Note:** This comparison is based on publicly documented product capabilities available in September 2026. It does not claim that every feature was independently tested. Confirm licensing, deployment, integration and data-residency details with each vendor before purchasing. ### The six AI governance platforms at a glance | Platform | Best fit | Publicly documented strengths | Main consideration | | --- | --- | --- | --- | | **Colchix** | European and regulated enterprises seeking operational governance across workforce AI | Shadow AI and AI-enabled SaaS discovery, identity context, reversible runtime tokenisation, EU-only audit evidence | European-first control plane focused on connecting discovery, protection and proof | | **Credo AI** | Organisations prioritising policy, regulatory intelligence and structured AI risk governance | AI registry, policy engine, risk classification, agent governance, compliance mapping and evidence recording | Best fit when formal governance workflows and regulatory context are the centre of the programme | | **Holistic AI** | Enterprises combining AI governance with model testing and continuous risk monitoring | Automated AI discovery, risk testing, bias and security assessments, approval workflows and audit trails | Validate integration depth and testing coverage for the organisation's actual AI stack | | **IBM watsonx.governance** | Large enterprises with complex model, risk and GRC environments | Governance graph, policy enforcement, continuous monitoring, AI risk management and regulatory content | Broad enterprise scope may require more implementation capacity than a focused deployment | | **OneTrust AI Governance** | Privacy, risk and compliance teams extending an existing OneTrust programme to AI | AI inventory, risk workflows, policy controls, runtime signals, prompt protection and audit evidence | Confirm which runtime capabilities and integrations support each required AI environment | | **ServiceNow AI Control Tower** | Enterprises already using ServiceNow, CMDB and integrated risk workflows | AI asset discovery, lifecycle governance, security context, observability, compliance workflows and value tracking | Most compelling when ServiceNow is already a strategic enterprise platform | This is a practical selection guide, not a laboratory ranking. Product scope changes quickly, and there is no standard independent benchmark covering all six platforms. ### What is an AI governance platform? An AI governance platform helps an organisation [identify, assess, control and document AI systems](https://colchix.com/blog/what-is-ai-governance) throughout their lifecycle. It should provide more than a register or compliance questionnaire. A useful platform helps answer: - Which AI systems, tools, models and agents are in use? - Who owns them, who uses them and for what purpose? - Which data enters or leaves each AI system? - Which policies, risks and legal obligations apply? - What technical control is enforced when AI is used? - Can the organisation prove what happened to an auditor, customer or regulator? The market includes several different product categories under the same label. Some platforms begin with model risk management. Others begin with GRC workflows, privacy operations, IT asset management, security monitoring or workforce AI. Buyers should therefore compare operating models, not just feature lists. For the distinction between documentation and operational control, read [Runtime AI Governance: Why Policy Alone Is Not Enough](https://colchix.com/blog/runtime-ai-governance). ### How we evaluated the platforms We assessed each platform against eight practical criteria: 1. **AI discovery and inventory:** Can it find AI rather than relying entirely on manual registration? 2. **Scope:** Does it govern employee tools, third-party AI, internal models, agents and AI-enabled SaaS? 3. **Risk and policy workflows:** Can it assign ownership, classify risk and manage approvals or exceptions? 4. **Runtime controls:** Can it apply or connect to technical controls while AI is operating? 5. **Data protection:** Can it identify or protect sensitive information entering AI systems? 6. **Evidence and auditability:** Does it retain useful, traceable records of decisions and controls? 7. **European operating fit:** Can deployment, data handling and evidence requirements support European organisations? 8. **Operational fit:** Does it align with the buyer's current cloud, GRC, privacy, security and workflow stack? The comparison uses vendor documentation, not undisclosed product testing. Where a capability is not clearly documented, it is not assumed. ### 1. Colchix: best for European-first runtime AI governance **Best for:** European organisations that want to connect workforce AI discovery, sensitive-data protection and audit evidence in one governance system. Colchix is an all-in-one AI governance platform for European enterprises. [ARGUS](https://colchix.com/agents/argus) identifies direct LLM use, AI-powered SaaS, OAuth exposure and personal-account access. [TALOS](https://colchix.com/agents/talos) protects sensitive information using reversible tokenisation before data reaches an external model. [ATHENA](https://colchix.com/agents/athena) records governed activity and produces evidence for compliance and audit workflows. The platform is designed around a simple operating principle: governance should happen where AI is used, not only in policies and periodic assessments. That creates a continuous path from **discovery**, to **protection**, to **proof**. #### Where Colchix stands out - European-first architecture and EU-only infrastructure. - Visibility into workforce use of direct LLMs and AI capabilities embedded in SaaS. - Identity and account context, including personal accounts outside enterprise SSO. - Reversible runtime tokenisation rather than relying only on blocking or destructive redaction. - Audit evidence generated from the same runtime governance layer. - Model-agnostic approach across global AI providers. #### What to verify Validate endpoint, connector and deployment coverage against the organisation's exact environment. Buyers should also distinguish between governing workforce interaction with AI and governing the technical development lifecycle of internally built machine-learning models; those requirements can involve different controls and integrations. **Bottom line:** Put Colchix on the shortlist when European control, Shadow AI visibility, runtime data protection and auditability must operate as one system. [Explore the Colchix platform](https://colchix.com/#platform) ### 2. Credo AI: best for policy and regulatory governance **Best for:** Enterprises building a formal AI governance programme around risk classification, regulatory intelligence, ownership and policy workflows. Credo AI is a purpose-built AI governance platform covering agents, applications, models and vendors. Its public documentation describes an AI registry, continuous risk intelligence and a policy engine with pre-built policy packs for frameworks including the EU AI Act, NIST AI RMF and ISO 42001. Credo AI's governance knowledge graph connects regulatory intelligence with business context. The platform also documents agent registries, dependency mapping, risk controls, policy-to-code translation, compliance mapping and evidence recording. #### Where Credo AI stands out - Purpose-built AI governance rather than a module added to a broader GRC suite. - AI and agent registry with risk classification and dependency mapping. - Strong policy and regulatory intelligence layer. - Governance workflows spanning design, development and production. - Broad integration catalogue across cloud, data, development and workflow tools. #### What to verify Confirm how AI assets are discovered in the organisation's specific environment and which runtime actions are enforced directly versus through connected monitoring or security tools. Buyers should also test how much configuration is required to translate policy packs into their own approval and evidence processes. **Bottom line:** Credo AI is a strong fit when structured risk governance, regulatory mapping and policy orchestration are the primary requirements. Source: [Credo AI — AI Governance Platform](https://www.credo.ai/). ### 3. Holistic AI: best for governance combined with AI testing **Best for:** Organisations that want AI inventory, governance workflows and technical testing for bias, safety, security and model performance. Holistic AI describes an end-to-end governance platform built around three functions: identify, protect and enforce. Its documented discovery scans cloud platforms, code repositories and SaaS applications to build an AI inventory. Its risk layer includes testing for bias, fairness, toxicity, hallucination, prompt injection, robustness and other model risks. The platform also maps risk scores and controls to frameworks including the EU AI Act, NIST AI RMF and ISO 42001, with approval workflows, deployment gates, audit trails and evidence collection. #### Where Holistic AI stands out - Automated discovery across models, agents, APIs, pipelines and workflows. - Technical testing across bias, safety, performance and security risks. - AI red teaming and adversarial testing capabilities. - Continuous monitoring for drift and degradation. - Compliance mapping, deployment gates and audit evidence. #### What to verify Validate which integrations provide automated discovery and which systems require manual onboarding. Confirm the applicability of available tests to the organisation's models, third-party AI services and workforce use cases. Testing depth matters more than the total number of available tests. **Bottom line:** Holistic AI belongs on the shortlist when governance and technical model assurance need to operate in the same programme. Source: [Holistic AI — Enterprise AI Governance Platform](https://www.holisticai.com/). ### 4. IBM watsonx.governance: best for large, complex enterprise environments **Best for:** Large enterprises that need AI governance integrated with model lifecycle management, enterprise risk and established GRC processes. IBM watsonx.governance provides a governance graph, enterprise controls and continuous accountability across AI systems. IBM documents policy enforcement, obligation mapping, evidence capture, continuous monitoring, risk management and regulatory content for frameworks including the EU AI Act, NIST AI RMF and ISO 42001. The platform also covers Shadow AI detection, relationships between systems and controls, AI value tracking and integration with broader IBM risk and governance capabilities. #### Where IBM stands out - Broad governance graph linking AI systems, policies, risks and controls. - Continuous monitoring and AI risk management across the lifecycle. - Strong regulatory and GRC content ecosystem. - Enterprise integrations and support for cloud and on-premises environments. - Suitable for complex multinational governance programmes. #### What to verify Clarify which IBM products, modules and professional services are necessary for the target architecture. Confirm how employee use of external AI, personal accounts and AI embedded inside SaaS is discovered in practice. Large platform breadth can be valuable, but only if the organisation has the operating capacity to implement it. **Bottom line:** IBM is a strong option for enterprises that need AI governance to connect with a wider model, risk and GRC architecture at global scale. Source: [IBM — watsonx.governance](https://www.ibm.com/products/watsonx-governance). ### 5. OneTrust AI Governance: best for privacy and risk-led programmes **Best for:** Organisations that already use OneTrust or want AI governance closely connected to privacy, data use, third-party risk and compliance workflows. OneTrust documents continuous AI discovery, inventory, automated risk tiering, approval workflows, runtime monitoring and audit evidence. Its platform covers systems, agents, models, datasets, vendors, projects and use cases, with templates for the EU AI Act, NIST AI RMF and ISO 42001. The platform also includes runtime capabilities: supported integrations can provide model and agent signals, while the OneTrust AI Guard SDK can identify and block or redact sensitive data in AI workflows before it reaches a model. #### Where OneTrust stands out - Strong connection between AI governance, privacy and enterprise risk workflows. - Automated intake, risk assessment, ownership and approval processes. - Runtime signals and policy violation tracking across supported platforms. - Prompt and response protection through an SDK-based control. - Audit-ready evidence connecting assessments, policies and enforcement actions. #### What to verify Confirm which runtime capabilities are native, SDK-based or dependent on supported third-party environments. Buyers should map each required AI channel—workforce tools, cloud models, internal applications and agents—to the exact OneTrust integration needed for visibility and enforcement. **Bottom line:** OneTrust is particularly relevant when privacy and risk teams already operate the organisation's governance programme and want to extend that control model to AI. Source: [OneTrust — AI Governance](https://www.onetrust.com/solutions/ai-governance/). ### 6. ServiceNow AI Control Tower: best for ServiceNow-centred enterprises **Best for:** Enterprises that already rely on ServiceNow and want AI assets, risks, controls and value connected to their CMDB and operational workflows. ServiceNow AI Control Tower is positioned as a central hub for discovering, securing, governing, observing and measuring AI. It documents automated inventory for agents, models and MCP servers, AI lifecycle management, risk and compliance workflows, security posture, observability and value tracking. Its main architectural advantage is context: AI assets can be represented inside the CMDB and connected to business services, ownership and enterprise workflows. #### Where ServiceNow stands out - AI discovery and inventory connected to the CMDB. - Lifecycle, case management and risk workflows in the ServiceNow platform. - Coverage of models, agents, copilots, MCP servers and datasets. - Governance content for the EU AI Act and NIST AI RMF. - AI performance, adoption and value tracking. #### What to verify Confirm which discovery methods and integrations cover the organisation's external AI tools, endpoints and unmanaged usage paths. Evaluate implementation effort and licensing across AI Control Tower and related ServiceNow products. The value is greatest when the organisation already has mature ServiceNow data and workflows. **Bottom line:** ServiceNow is a natural shortlist option when AI governance must become part of an existing ServiceNow operating model rather than a separate control plane. Source: [ServiceNow — AI Control Tower](https://www.servicenow.com/products/ai-control-tower.html). ### Which AI governance platform should you choose? Use these decision rules as a starting point: - **Choose Colchix** when European sovereignty, workforce AI discovery, reversible runtime protection and audit evidence must operate together. - **Choose Credo AI** when regulatory intelligence, policy orchestration and formal AI risk workflows are the centre of the programme. - **Choose Holistic AI** when technical model testing, AI red teaming and continuous risk monitoring are central requirements. - **Choose IBM watsonx.governance** when AI governance must integrate with a complex multinational model and GRC environment. - **Choose OneTrust** when privacy, data governance and risk teams already lead the governance programme. - **Choose ServiceNow** when the CMDB and ServiceNow workflows are the organisation's operational system of record. The shortlist should follow the operating model. A platform optimised for internal model validation is not automatically the best product for employee use of ChatGPT, Claude or AI-enabled SaaS. Likewise, a workforce AI control layer does not replace every model testing or development-governance requirement. ### Why European enterprises need a different evaluation European buyers should evaluate more than whether a platform includes an “EU AI Act” template. A credible assessment also covers: - Where prompts, logs, evidence, identifiers and encryption keys are processed and stored. - Whether personal data or confidential information reaches an external AI provider in plain text. - Whether the platform can distinguish approved enterprise accounts from personal AI use. - How it supports data minimisation, retention, access control and international transfer requirements. - Whether technical controls generate evidence that can be reviewed by a DPO, auditor or regulator. - Whether it covers AI embedded inside software, agents and third-party services—not only registered models. - How governance continues when employees use global AI providers. The EU AI Act is only one part of the decision. GDPR, sector rules, contractual confidentiality, cybersecurity requirements and internal accountability also shape the control architecture. The European Commission describes the AI Act as a risk-based framework for providers and deployers, but software selection still needs to follow the organisation's actual AI systems and role in each use case. Source: [European Commission — AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai). ### Questions to ask every AI governance vendor 1. How does the platform discover AI that has never been manually registered? 2. Does it cover employee tools, personal accounts, AI-enabled SaaS, internal models, APIs, agents and MCP servers? 3. Which controls operate in real time, and which are documentation or workflow controls? 4. Can it prevent or transform sensitive data before that data reaches an external model? 5. Where are prompts, metadata, logs, evidence and keys processed and stored? 6. How does it assign ownership, approve use cases and manage exceptions? 7. Can policies be mapped to technical controls and observable evidence? 8. Which EU AI Act, GDPR, ISO 42001 and NIST AI RMF workflows are included? 9. Can evidence be exported for auditors, customers, regulators and internal investigations? 10. Which capabilities require additional modules, SDKs, agents, gateways or professional services? 11. How does the platform govern material changes to models, agents, data and intended use? 12. What can be demonstrated in a proof of concept using the organisation's real architecture? Ask vendors to demonstrate the same representative scenarios. Include an approved enterprise LLM, a personal AI account, an AI feature embedded in SaaS, an internally developed model, a third-party AI vendor and an agent connected to enterprise data. Use synthetic sensitive data during testing. ### Governance software does not remove governance responsibility No platform can decide an organisation's risk appetite, legal role or accountability structure automatically. Technology can discover assets, automate workflows, apply controls and retain evidence, but the organisation must still define: - Who can approve AI use. - Which data may enter each system. - Which uses require human oversight. - What evidence must be retained. - Who owns remediation when policy is violated. - When an AI system must be restricted or withdrawn. The strongest implementation combines clear accountability with technical controls. A policy without visibility cannot be enforced; a dashboard without ownership cannot drive action; and protection without evidence is difficult to prove. For a practical look at the discovery layer, read [Best Shadow AI Detection Tools in 2026](https://colchix.com/blog/best-shadow-ai-detection-tools-2026). ### Final verdict The best AI governance platform for a European enterprise is the one that governs the AI the organisation actually uses and produces evidence that its controls work. Colchix is the European-first option for organisations seeking Shadow AI discovery, reversible runtime data protection and audit evidence in one model-agnostic platform. Credo AI is strong in policy and regulatory governance. Holistic AI combines governance with technical AI testing. IBM provides broad enterprise model and GRC coverage. OneTrust connects AI governance with privacy and risk operations. ServiceNow integrates governance with the CMDB and enterprise workflows. Do not select a platform from an “EU AI Act ready” claim alone. Build an inventory of real AI usage, identify the data and evidence that matter, and test the platform against the organisation's blind spots before committing. ### Frequently asked questions #### What is the best AI governance platform for European enterprises? There is no universal winner. Colchix fits organisations prioritising European control, workforce AI visibility, runtime data protection and audit evidence. Credo AI is strong for policy and risk governance; Holistic AI for testing and continuous monitoring; IBM for complex enterprise environments; OneTrust for privacy-led programmes; and ServiceNow for organisations centred on its CMDB and workflows. #### What should an AI governance platform include? At minimum, it should provide an AI inventory, ownership, risk classification, policy workflows, lifecycle records and audit evidence. Depending on the use case, organisations may also need automated discovery, runtime monitoring, sensitive-data protection, model testing, agent governance and technical policy enforcement. #### Is an AI inventory enough for EU AI Act compliance? No. An inventory is a foundation, not complete compliance. Obligations depend on the organisation's role, the system's risk category and the specific use case. Governance may also require risk management, technical documentation, human oversight, monitoring, transparency and evidence. #### What is the difference between AI governance and AI security? AI governance defines ownership, acceptable use, risk decisions, policies and accountability. AI security protects AI systems, data and interactions from threats or misuse. They overlap at runtime, but neither replaces the other. Effective programmes connect governance decisions to enforceable security controls. #### Can AI governance software detect Shadow AI? Some platforms can. The depth varies considerably: discovery may come from endpoints, cloud integrations, code repositories, CMDB data, network controls or manual registration. Buyers should test personal accounts, embedded AI features, desktop applications, APIs and agents rather than relying on a vendor's total asset count. #### Does EU hosting make an AI governance platform sovereign? Not by itself. Buyers should also assess corporate jurisdiction, subprocessors, support access, encryption-key control, international transfers, telemetry, backups and where sensitive data is processed. Data-centre location is one part of a wider sovereignty assessment. --- Source: https://colchix.com/blog/best-ai-governance-platforms-europe-2026 ## The AI Act Enforcement Timeline: What's Real and What's Delayed > Vendor marketing still runs 'AI Act deadline: August 2026' messaging that's a year out of date. Here's what's actually in force, what's delayed, and what to check before it shapes a budget decision. Colchix Team & Gianni Valerio, CEO · Published 17 August 2026 · Updated 12 October 2026 · AI Act & Regulation · 5 min read **In short:** "AI Act deadline: August 2026" is out of date for the obligations it's usually attached to. Article 4 (AI literacy, since February 2025), the general-purpose AI obligations (since 2 August 2025) and Article 50 transparency (since 2 August 2026) are in force. After the Digital Omnibus, the Annex III high-risk rules apply from 2 December 2027 and Annex I from 2 August 2028. A lot of AI compliance marketing is currently running on a timeline that's out of date. "AI Act deadline: August 2026" is still a common line in vendor pitches and LinkedIn posts, and for the specific obligations it's usually attached to, it's no longer accurate. The 2026 Digital Omnibus changed the schedule, and the gap between what vendors are saying and what's actually in force is wide enough that it's worth checking before it shapes a budget or urgency decision. ### What's actually in force right now Three obligations that matter for most enterprises are live today, and none were affected by the Digital Omnibus delay: **Article 4 — AI literacy.** Applicable since **February 2025**, this requires providers and deployers of AI systems to ensure staff involved in operating them have a sufficient level of AI literacy, relative to their technical knowledge, experience, and the context of use. This is a current, active obligation — not a future deadline, and one many organizations haven't yet documented compliance with. **Chapter VII — GPAI and governance obligations.** Applicable since **2 August 2025**, these cover general-purpose AI models placed on the market from that date — technical documentation, training content summaries, and copyright compliance obligations for GPAI providers. Legacy models already on the market have an extended transition window until August 2027. **Article 50 — transparency.** Applicable since **2 August 2026**, this introduces specific transparency obligations: informing people when they're interacting with an AI system (unless obvious from context), machine-readable marking of AI-generated synthetic content, and disclosure requirements for deepfakes and AI-generated content on matters of public interest. The European Commission published detailed guidelines on these obligations in July 2026. Both Article 4 and Article 50 apply independently of high-risk classification, but Article 50 applies only to the specific transparency scenarios it covers — including direct AI interaction, synthetic content, deepfakes, and certain deployer use cases — not to every enterprise AI use broadly. ### What got delayed, and by how much The obligation most vendor marketing references when it says "August 2026 deadline" is the set of requirements for high-risk AI systems under Annex III — conformity assessments, technical documentation, human oversight mechanisms, and related obligations for systems used in areas like employment, credit scoring, law enforcement, and critical infrastructure. Following the Digital Omnibus, which entered into force in July 2026, that timeline changed: - **High-risk AI systems under Annex III** — application extended to **2 December 2027**. - **High-risk AI embedded in regulated physical products** (machinery, toys, lifts, and similar categories under Annex I) — application extended to **2 August 2028**. The stated rationale was to allow more time for the technical standards and conformity assessment infrastructure the high-risk obligations depend on to actually be ready — those standards weren't fully finalized on the original schedule, and enforcing conformity assessment requirements against standards that don't exist yet isn't workable in practice. ### Why the outdated messaging persists A few structural reasons vendor marketing hasn't caught up, worth naming plainly rather than assuming bad faith: **Content built before the delay is still live.** A lot of "AI Act deadline" content — landing pages, blog posts, sales decks — was written when August 2026 was genuinely the relevant date for Annex III obligations. Updating it requires someone to notice the change and revise published material, which doesn't happen automatically. **Urgency sells, and the old date is more urgent-sounding.** "Deadline in months" creates more buying pressure than "deadline in over a year," and that incentive doesn't automatically correct itself even after the facts change. **The regulatory picture genuinely is complicated.** Article 4, Chapter VII, and Article 50 are in force on different dates. Annex III and Annex I are delayed to different dates again. A vendor conflating "the AI Act" as a single deadline, rather than a set of obligations with different dates and different scopes, isn't necessarily being deliberately misleading — it's collapsing real complexity into a simpler, less accurate story. ### What this means for a budget or vendor decision right now None of this means AI Act compliance can wait. It means the specific obligations driving urgency should be named accurately, because the right infrastructure decision depends on which timeline actually applies to your organization. If your organization deploys or is developing systems that will fall under Annex III high-risk classification — HR/recruitment tools, credit or insurance underwriting, biometric systems, among others — you have until December 2027 for those specific conformity and documentation obligations, which is meaningful planning time, not a today problem. If your organization [deploys AI tools across the workforce](https://colchix.com/blog/what-is-ai-governance), Article 4 (AI literacy) already matters today. Article 50 may also apply, depending on how those systems are deployed and whether the organization's use falls within one of its specific transparency scenarios — it's worth checking against your actual use case rather than assuming it applies uniformly. Confusing the delayed and active obligations risks either panic-buying for a deadline that isn't imminent, or — the more common mistake — assuming "the AI Act deadline got delayed" means nothing is currently required, which isn't true either. ### A short list of questions worth asking any vendor citing an "AI Act deadline" - **Which specific article or annex are you referring to?** "The AI Act" isn't one deadline — a vendor citing a single date without specifying the obligation is either simplifying inaccurately or hasn't tracked the update. - **Is this obligation affected by the Digital Omnibus?** Article 4, Chapter VII, and Article 50 weren't. Annex III and Annex I were, substantially. - **What happens if we wait?** For Annex III-scope systems, waiting until closer to December 2027 may be entirely reasonable, depending on implementation complexity. For Article 4 and applicable parts of Article 50, the obligation is already active. ### The bottom line Regulatory timelines shift, and August 2026 shifted meaningfully for the highest-profile part of the AI Act — the high-risk system obligations most compliance marketing was built around. What didn't shift: [AI literacy and GPAI governance obligations](https://colchix.com/blog/ai-act-vs-gdpr) that are active today, for organizations of essentially every size and sector using AI tools. The practical move isn't waiting for clarity or reacting to the loudest deadline claim — it's checking which specific obligation applies to your actual use case, and building toward that, not toward a generic "AI Act deadline" that may no longer describe anything real. ### Frequently asked questions #### Which EU AI Act obligations are in force now? Article 4 on AI literacy, since February 2025; Chapter VII's general-purpose AI obligations, since 2 August 2025 for models placed on the market from that date; and Article 50's transparency obligations, since 2 August 2026. None were affected by the Digital Omnibus delay. #### When do the high-risk AI rules apply? Following the Digital Omnibus, which entered into force in July 2026, the high-risk obligations for Annex III systems apply from 2 December 2027, and those for high-risk AI embedded in regulated products under Annex I from 2 August 2028. #### Does the delay mean nothing is required yet? No, and that's the more common mistake. AI literacy under Article 4 already applies to organizations using AI tools across the workforce, and Article 50 may apply depending on how AI systems are deployed. Only the high-risk conformity and documentation obligations moved. #### What should I ask a vendor citing an "AI Act deadline"? Which article or annex they mean, whether that obligation was affected by the Digital Omnibus, and what actually happens if you wait. "The AI Act" isn't one deadline but a set of obligations with different dates and scopes. --- Source: https://colchix.com/blog/ai-act-enforcement-timeline ## AI Audit Trail: What Regulators Actually Ask For > When a regulator or DPO asks for evidence of AI activity, 'we have a policy' isn't an answer. Here's what a real AI audit trail needs to contain — and why most organizations don't have one. Colchix Team & Gianni Valerio, CEO · Published 16 August 2026 · Updated 12 October 2026 · Runtime Governance · 5 min read **In short:** An AI audit trail is a continuous, structured record of AI activity: which employee used which tool, with what category of data, where it went and what control applied. Regulators and DPOs ask for demonstrated behavior, not policies, and a record reconstructed after the request carries far less weight than one that already existed. The trail is the natural output of runtime governance, not a separate project. The moment a DPO or regulator asks "show me what AI systems processed personal data in the last quarter, and how you controlled that," most organizations discover the gap between having a governance policy and having governance evidence. A policy describes intent. An audit trail is evidence of what happened, and building one after the fact — reconstructed from memory, Slack messages, and partial logs — is not the same thing as having had one running. ### What "audit trail" actually means here An AI audit trail is a structured, continuous record of AI activity within an organization: which employee used which tool, what category of data was involved, when it happened, and what controls applied. It's not a single document — it's a live dataset, built automatically as AI interactions occur, retained in a form that can be queried and produced on demand. The distinction that matters: an audit trail is evidence of what happened, not a description of what should happen. A signed AI usage policy, a training deck, a list of approved tools — these describe intent, and regulators generally aren't asking for intent. They're asking for demonstrated behavior. A reliable audit trail is what turns that answer from a policy claim into operational evidence. ### What a regulator or DPO actually asks for Requests vary by framework and context, but they converge on a consistent set of underlying questions: - **Which AI systems processed personal data, and for what purpose?** Not a list of approved tools — an actual record of use, [including tools nobody formally approved](https://colchix.com/blog/what-is-shadow-ai). - **What categories of data were involved?** Personal data, special category data, financial information, health records — the specific classification matters for assessing severity and scope. - **Under what authorization, purpose, and governance framework did the processing occur?** GDPR accountability requires organizations to connect processing activity to an established purpose, lawful basis, and appropriate controls — not simply state that an employee chose to use the tool. - **What technical and organizational measures were in place?** This is where AI Act oversight requirements and [GDPR Article 25/30 obligations](https://colchix.com/blog/ai-act-vs-gdpr) converge — evidence of controls, not just evidence of intent to have controls. - **Can you demonstrate this wasn't an isolated incident review, but continuous practice?** A one-time audit conducted after a complaint looks very different, credibility-wise, from a system that has been logging this continuously all along. None of these are satisfied by a policy document, however well-written. Each requires an actual record. ### Why "we have a policy" fails as an answer A policy answers "what were employees told to do." None of the questions above ask that. They ask what actually happened, to whom, with what data, under what authority — questions a policy document has no mechanism to answer, because a policy doesn't observe anything. It states an intention and stops. This gap becomes acute specifically during an investigation, because investigations happen after something already occurred — the organization needs to explain a specific past event, not a general intention. "Our policy prohibits pasting client data into unapproved AI tools" is not an answer to "did that happen, and if so, when, by whom, and with what data." Only a log can answer that question, and only if the log existed before the question was asked. ### What a defensible audit trail actually needs to contain Four components, consistently, across GDPR and AI Act contexts — **WHO** used AI, **WHAT** category of data was involved, **WHERE** it was sent, **WHAT CONTROL** was applied: 1. **Identity and authorization.** Which employee, under what role or authorization, initiated the interaction — not anonymized activity, but attributable, auditable records. 2. **Data classification.** What category of data was involved — not necessarily the full content of every prompt, but enough classification (personal data, financial, health, IP) to assess exposure and regulatory relevance without unnecessarily exposing prompt contents themselves. 3. **Tool and destination.** Which AI system received the query, where the data was processed, and what relevant transfer and data-processing safeguards applied. 4. **Controls applied.** What happened at the point of use — [was sensitive data tokenized](https://colchix.com/blog/tokenization-vs-redaction), blocked, allowed through unmodified — and why, mapped to the policy or rule that triggered that outcome. Missing any one of these turns the record into a partial answer. A log of "AI tool used" without data classification tells a regulator nothing about severity. A log of data classification without identity and authorization can't establish accountability. The four need to exist together, consistently, not as four separate systems that happen to overlap. ### Why retroactive reconstruction doesn't hold up When an organization gets asked for evidence it doesn't already have, the common response is trying to reconstruct it after the fact — pulling together whatever partial logs exist (network access records, ticketing systems, employee interviews) into something that resembles an answer. This approach has a structural credibility problem beyond simple incompleteness: a reconstructed record, assembled specifically in response to a request, invites the question of whether it's complete, accurate, or shaped by hindsight. A continuous log that existed independently of any specific request — generated automatically as a byproduct of normal operation, not compiled defensively after the fact — carries fundamentally different evidentiary weight. Regulators and auditors are generally aware of this distinction, even when it isn't stated explicitly in a request. The cost of missing evidence isn't limited to regulatory exposure. It turns audits into manual investigations, pulls Security, Legal, and IT into evidence collection, and makes incident scope harder to establish precisely — a cost measured in weeks of internal time, not just potential fines. ### How this connects to runtime governance An audit trail isn't a separate system bolted onto AI governance — it's the natural output of governance operating correctly. If visibility, protection, and control are genuinely happening at the point of use ([the runtime layer](https://colchix.com/blog/runtime-ai-governance)), the audit trail is simply the record of that activity, generated as a byproduct rather than assembled as a separate compliance project. This is why organizations that try to build "just the audit trail piece" without the underlying runtime visibility and protection tend to end up with a log of access events — who visited what domain — rather than a log of governed AI activity. The audit trail is only as good as what the underlying system actually saw and controlled. A log can't document protection that never happened. ### The bottom line When the question is "what did your AI systems actually do," a policy is not evidence, and a log built after the request is not the same as a log that already existed. A defensible AI audit trail is continuous, attributable, classified, and generated automatically as normal operation — not assembled under pressure once someone asks. Building that infrastructure before it's needed is the difference between answering a regulator's question with a report and answering it with a scramble. ### Frequently asked questions #### What is an AI audit trail? A structured, continuous record of AI activity within an organization: which employee used which tool, what category of data was involved, when it happened and what controls applied. It's a live dataset built automatically as AI interactions occur, retained so it can be queried and produced on demand. #### What do regulators ask for about AI use? Which AI systems processed personal data and for what purpose; which categories of data were involved; under what authorization, purpose and lawful basis; what technical and organizational measures were in place; and whether this is continuous practice rather than a one-off review after a complaint. #### What must an AI audit trail contain? Four components, together: identity and authorization (who); data classification (what category of data, without exposing full prompt contents); tool and destination (where the data was sent and processed); and the control applied (tokenized, blocked or allowed, and under which rule). #### Can an audit trail be reconstructed after a request? Not credibly. A record assembled in response to a request invites questions about completeness and hindsight, while a log generated automatically as part of normal operation carries different evidentiary weight. Reconstruction also turns audits into weeks of manual investigation across Security, Legal and IT. --- Source: https://colchix.com/blog/ai-audit-trail ## AI Data Leakage: How Sensitive Data Actually Reaches LLMs > AI data leakage isn't hypothetical — it's a predictable pattern that happens the same way across industries. Here's how it actually occurs, and where most defenses fail to catch it. Colchix Team & Gianni Valerio, CEO · Published 15 August 2026 · Updated 12 October 2026 · Data Protection · 5 min read **In short:** AI data leakage rarely looks like a breach. It happens through legitimate work: an employee gives an AI tool a contract, a customer record, source code or unreleased figures to get a useful answer, and the data reaches infrastructure the organization doesn't control. It goes unnoticed because no transfer looks unusual, chatting doesn't feel like sending data, and most monitoring sees access, not content. AI data leakage doesn't usually happen the way security awareness training implies — a careless click, a phishing link, a deliberate insider threat. It happens through completely legitimate work, performed by [employees trying to do their job faster](https://colchix.com/blog/what-is-shadow-ai), using tools that make that entirely possible in a way no previous generation of software did. Understanding the actual pattern matters more than imagining a dramatic breach scenario, because the real pattern is what security controls need to be built around. ### The pattern, not the exception Across regulated industries, the shape of AI data leakage repeats with remarkable consistency: an employee has a task, a deadline, and an AI tool that can plausibly help. The task requires context — a contract, a customer record, source code, financial figures — so the employee provides that context to get a useful answer. The AI tool now has data it was never meant to receive, on infrastructure the organization doesn't control, and there may be no reliable record inside the organization of what was actually shared. This isn't a security failure in the traditional sense — nobody circumvented a firewall or exploited a vulnerability. It's a gap between what the AI tool needs to do its job well and what the organization is actually authorized, contractually or legally, to hand over. That gap is invisible until something goes wrong, and by the time it's visible, the data has already left. ### What this looks like across functions **Legal and contracts.** An in-house counsel pastes a draft NDA into ChatGPT to check the language against a template, including the counterparty's name, deal terms, and confidentiality clauses that explicitly prohibit sharing the document outside the immediate deal team. The AI tool wasn't part of that team, and nobody assessed whether the transfer breached the confidentiality clause itself. **Customer support.** An agent pastes a customer's full support ticket — name, account details, sometimes payment or health information depending on the industry — into an AI tool to draft a more polished response. The customer's personal data, protected under GDPR, now sits on a third-party AI provider's infrastructure, potentially processed outside the safeguards, purposes, and vendor arrangements the organization originally established for that data. **Engineering.** A developer copies a proprietary code snippet, sometimes including embedded API keys or internal architecture details, into an AI coding assistant to debug an issue under deadline pressure. Source code is intellectual property; depending on the tool and its terms, that snippet may now be retained on infrastructure outside the organization's control. **Finance.** An analyst feeds unreleased quarterly figures into an AI tool to help draft internal commentary or check the phrasing of an earnings summary. For public companies, this touches material non-public information — a category with regulatory consequences well beyond a typical data protection concern. **HR.** A manager uploads employee performance reviews or compensation data to an AI tool to help draft feedback more diplomatically, believing the data is anonymized enough to be safe. It rarely is — names, role titles, and specific project references usually make individuals identifiable even without an explicit name attached. None of these employees intended to cause a data protection incident. Each one was solving a real problem with the tool that happened to be available and effective. ### Why the leakage often goes undetected Three structural reasons this pattern persists without organizations noticing: **No transfer event looks unusual.** Traditional data loss prevention tools were built to catch large file transfers, unusual download volumes, or data leaving through recognizable exfiltration channels. A conversational AI prompt doesn't necessarily resemble traditional exfiltration. It can be a few paragraphs typed into an ordinary browser session — far less obvious than a bulk download or large file transfer. **The employee doesn't experience it as a data transfer.** Psychologically, typing into a chat interface feels like asking a question, not like sending a file to an external party. The interface feels conversational. The underlying event is still data leaving one environment and entering another. That framing gap matters, because it means employees who would think twice before emailing a contract to an unknown address don't apply the same caution to an AI chat window, even though the underlying data movement is comparable. **No one is looking at content, only access.** Most existing monitoring tools that do see AI tool usage — [CASB platforms, endpoint monitoring](https://colchix.com/blog/shadow-ai-detection) — see that a domain was visited, not what was actually sent. Confirming an employee visited chat.openai.com tells you nothing about whether they pasted a customer's medical record or asked a general question about email etiquette. Without visibility into the content of the exchange, there's no way to distinguish routine, harmless use from an actual leakage event. ### Why the compliance exposure compounds A single instance of AI data leakage is a real but often limited risk. What makes it a serious ongoing exposure is that it doesn't stay a single instance — it repeats across every employee who discovers the same shortcut, at a scale that individual incident response can't keep pace with. [Under GDPR](https://colchix.com/blog/ai-act-vs-gdpr), each unassessed transfer to an external AI service is a potential accountability gap — an organization is expected to have assessed the lawful basis and cross-border implications of processing before it happens, not after a regulator asks. Under sector-specific confidentiality obligations — attorney-client privilege, doctor-patient confidentiality, banking secrecy — the exposure isn't just regulatory; it can undermine the legal protections those relationships depend on. And practically, an organization that can't say with confidence what data has and hasn't reached external AI tools has no reliable way to scope a breach notification if something does go wrong later — the uncertainty itself becomes a liability. ### What actually catches this before it happens The three structural gaps above point directly to what a real defense needs to address, together: 1. **Visibility into content, not just access.** Knowing an AI tool was used matters less than knowing what category of data was involved — the difference between a harmless question and a leakage event. 2. **[Protection that intervenes before the transfer completes](https://colchix.com/blog/tokenization-vs-redaction),** not detection that flags it afterward. By the time a leakage event is logged after the fact, the data has already reached the external tool — [the record is useful for audit](https://colchix.com/blog/ai-audit-trail), but it didn't prevent the exposure. 3. **A control that doesn't depend on the employee recognizing the moment as risky.** Since the psychological framing of a chat query doesn't feel like a data transfer, the control can't rely on the employee pausing to think about it — it has to operate regardless of whether they do. ### The bottom line AI data leakage isn't an edge case requiring an unusual set of circumstances — it's the predictable outcome of giving employees fast, effective tools without a technical layer that understands what's actually flowing through them. The pattern is consistent enough across industries and functions that it's less useful to think of it as a series of incidents to respond to, and more useful to treat it as a structural gap to close — one that exists the moment an AI tool has access to a browser and an employee has a deadline. ### Frequently asked questions #### How does sensitive data actually reach LLMs? Through ordinary work. An employee has a task, a deadline and an AI tool that can help; the task needs context, such as a contract, a customer record, source code or financial figures, so the employee provides it. The tool now holds data it was never meant to receive, on infrastructure the organization doesn't control. #### Why doesn't traditional DLP catch AI data leakage? Traditional data loss prevention was built for large file transfers, unusual download volumes and recognizable exfiltration channels. A prompt can be a few paragraphs typed into an ordinary browser session, and most tools that do see AI usage see the domain visited, not what was sent. #### Which teams are most exposed? Every function that works with sensitive context: legal pasting contract drafts, support agents pasting customer tickets, engineers pasting proprietary code that may embed API keys, finance analysts using unreleased figures, and HR managers uploading reviews that are rarely as anonymized as they seem. #### What prevents AI data leakage? Three things together: visibility into the content of AI interactions, not just access; protection that intervenes before the transfer completes rather than flagging it afterwards; and a control that works whether or not the employee recognizes the moment as risky. --- Source: https://colchix.com/blog/ai-data-leakage ## Shadow AI Detection: How to See What Your Team Actually Uses > You can't govern AI usage you can't see. Here's what actually works for detecting shadow AI inside an organization — and why most approaches only catch half of it. Colchix Team & Gianni Valerio, CEO · Published 14 August 2026 · Updated 12 October 2026 · Shadow AI · 5 min read **In short:** Most shadow AI detection methods each catch a slice: network monitoring sees domains, not employees or data; CASB and SSE platforms see access, not the interaction; endpoint tools miss unmanaged devices; surveys under-report. Runtime detection observes AI interactions as they happen in the environments the organization controls, and delivers a live inventory, risk context and a record that holds up when a DPO or regulator asks. Every conversation about shadow AI eventually arrives at the same practical question: fine, [employees are using unapproved AI tools](https://colchix.com/blog/what-is-shadow-ai) — how do you actually find out which ones, and who's using them? The honest answer is that most detection methods only catch part of the picture, and knowing which part each one misses is the difference between a security team that thinks it has visibility and one that actually does. ### Why this is harder than detecting shadow IT Traditional shadow IT detection relied on signals that AI usage often doesn't produce. An unapproved SaaS tool usually needed an account with a company email, a browser extension install, sometimes an expense report. Each of those left a trace somewhere a security team could look. AI usage frequently leaves none of that. An employee can open ChatGPT in an incognito tab, log in with a personal Gmail account, and never touch anything the organization's identity provider or endpoint tooling would notice. No install. No corporate SSO. No expense line. The interaction happens entirely inside a browser session that, from the network's perspective, looks like ordinary web traffic to a domain that isn't inherently suspicious. This is why "we'll just check our approved software list" — the default first move for most IT teams — catches almost nothing. It only shows what was approved, which by definition excludes everything shadow AI actually is. ### The detection methods that exist, and what each one misses **Network traffic monitoring.** Inspecting DNS requests or traffic patterns to known AI domains (chat.openai.com, claude.ai, gemini.google.com, and dozens more) can reveal that someone on the network visited those domains. What it typically can't reveal: which employee, what they sent, or whether the visit happened on a personal device using mobile data instead of the corporate network — which is exactly what happens once employees learn the network is being watched. **CASB (Cloud Access Security Broker) and modern SSE platforms.** Increasingly capable of detecting access to known GenAI services and applying useful access controls, and several major vendors are actively adding GenAI-specific discovery. The limitation is depth, not absence: identifying that a user accessed an AI service is different from understanding the AI interaction itself — classifying the data involved, and producing AI-specific governance evidence rather than a network access log entry. **Browser extension and endpoint monitoring.** Can log which sites an employee visited on a managed device, which is genuinely useful — but says nothing about what was typed into the page, and nothing at all about unmanaged personal devices, which employees increasingly prefer specifically because they aren't monitored. **Self-reported surveys.** Asking employees to disclose which AI tools they use produces data that's directionally useful and reliably incomplete — people underreport tool use they suspect isn't sanctioned, not out of dishonesty, but because admitting it feels like admitting a policy violation, even when the actual violation is the absence of a sanctioned alternative. **Employee reporting or spot-checks.** Occasionally surfaces something real, but isn't a detection method — it's luck, and it doesn't scale past a handful of incidents. Each of these catches a slice. None of them, alone or combined, produces continuous, comprehensive visibility — because they were all built to answer a narrower question than the one that actually matters: not "did traffic hit this domain" but "what AI tool did this specific employee use, with what data, and when." ### What actual runtime detection looks like The gap all of the above share is timing and scope: they're either reactive (checking logs after the fact) or partial (only seeing managed devices, or only network-level traffic without content). This means the detection layer sits at the point where the AI query actually leaves the organization's perimeter — not watching for a domain name to appear in a log, but actively identifying the interaction: which employee, which AI tool, what category of data is in the request. Runtime detection closes these gaps by observing AI interactions as they occur across the environments under organizational control — managed devices, corporate network and proxy traffic, browser-level visibility where deployed — rather than relying solely on retrospective logs or a static list of approved applications. Detection shouldn't depend exclusively on a known-tools list either: [a runtime layer](https://colchix.com/blog/runtime-ai-governance) can combine known-tool identification with behavioral and traffic signals to surface AI usage as it happens, including tools that launched last month and don't appear on anyone's approved list yet. The practical difference this makes: a new AI tool doesn't need to be added to a blocklist or an approved-tools list to be visible within the organization's controlled environment. It gets surfaced as usage occurs, not months later when someone happens to notice. ### What good shadow AI detection actually delivers Three things, together, not any one alone: 1. **A live inventory, not a point-in-time snapshot** — continuously updated as new tools appear in usage, not refreshed on a quarterly audit cycle that's already stale by the time it's reviewed. 2. **Risk context, not just a tool list.** Knowing that 40 employees use ChatGPT is less useful than knowing which of those sessions involved something resembling client contract language or financial figures. Detection without risk signal produces a long list nobody has time to act on. 3. **A record that survives being asked about.** If a DPO or a regulator asks what AI tools processed personal data in the last quarter, the answer needs to be a report pulled from continuous monitoring, not a reconstruction assembled from partial network logs and guesswork. ### What this means in practice Detection is the precondition for everything else in AI governance, not a nice-to-have layered on top. An organization can have well-designed data protection policies, [solid tokenization tooling](https://colchix.com/blog/tokenization-vs-redaction), and [a clean audit process](https://colchix.com/blog/ai-audit-trail) — and none of it matters for the AI usage it never saw happening in the first place. You cannot govern, protect, or produce evidence about an interaction that never registered anywhere. This is also why detection alone, without action, is an incomplete answer. Seeing that an employee used an unapproved tool with sensitive data is useful. Seeing it and being able to protect that data before it left the organization — in the same moment, not after a security team reviews the log a week later — is the actual goal. Detection tells you what's happening. It's the first of three capabilities, not a finish line. ### Frequently asked questions #### Why is shadow AI harder to detect than shadow IT? Shadow IT left traces: company-email accounts, extension installs, expense reports. An employee can use AI in an incognito tab with a personal account, with no install, no corporate SSO and no expense line; on the network it looks like ordinary web traffic to a domain that isn't inherently suspicious. #### Can network monitoring or a CASB detect shadow AI? Partly. Network monitoring can show that someone visited a known AI domain, but typically not which employee, what they sent, or anything on a personal device using mobile data. CASB and SSE platforms increasingly detect access to known GenAI services, but identifying access is different from understanding the interaction and the data involved. #### What should shadow AI detection deliver? Three things together: a live inventory updated as new tools appear in use, not a quarterly snapshot; risk context, such as which sessions involved contract language or financial figures; and a record that holds up when a DPO or regulator asks which AI tools processed personal data. #### Is detection enough on its own? No. Detection is the precondition for AI governance, not the finish line. Seeing that an employee used an unapproved tool with sensitive data is useful; protecting that data before it leaves the organization, in the same moment, is the actual goal. --- Source: https://colchix.com/blog/shadow-ai-detection ## AI Governance vs AI Security: What's the Difference? > They get used interchangeably in vendor pitches, but AI governance and AI security solve different problems. Here's the distinction that actually matters when evaluating a solution. Colchix Team & Gianni Valerio, CEO · Published 13 August 2026 · Updated 12 October 2026 · AI Governance · 2 min read **In short:** AI security protects an AI system from attack: jailbreaks, manipulation and adversarial inputs. AI governance controls what happens to an organization's data when employees use any AI system, built in-house or not, and proves that control existed. Organizations building their own AI products need both, but most regulated enterprises carry governance exposure from everyday AI use, not security exposure from models of their own. Vendor pitches use "AI governance" and "AI security" almost interchangeably, and that's a problem, because they're answers to different questions. Confusing them leads directly to a specific, expensive mistake: buying a well-reviewed AI security product and discovering, months later, that it was never going to solve the compliance gap that actually mattered. ### Two different questions **AI security** asks: is this AI system safe from attack? Can it be jailbroken, manipulated into leaking its training data, tricked into ignoring its safety instructions, or exploited through adversarial inputs? It's a discipline focused on the model and the application built around it — protecting the system from people trying to break it. **AI governance** asks a different question entirely: what happens to our organization's data when our employees use any AI system, whether we built it or not? It's not about hardening a model against attack. It's about [controlling what flows into and out of AI tools](https://colchix.com/blog/what-is-ai-governance), and being able to prove that control existed when someone asks. A useful way to hold the distinction: AI security protects the model from the world. AI governance protects the organization from how the model — any model — gets used. ### Why the confusion is expensive The practical cost shows up in procurement. A security team evaluating "AI protection" vendors often ends up comparing tools that don't actually solve the same problem, because both get pitched under similar language. An AI red-teaming platform or prompt-injection defense tool is primarily an AI security product — it protects an AI system your organization has built or deployed from being attacked or manipulated. Some LLM firewalls sit across both categories, depending on whether they protect the model itself, govern enterprise data flows, or do both. None of these necessarily do anything about [an employee pasting a client contract into the public ChatGPT interface](https://colchix.com/blog/ai-data-leakage), because that isn't an attack on a model. It's an ungoverned data flow to a model your organization doesn't control at all. Conversely, an organization can have zero AI security concerns — no custom models, no in-house AI product — and still carry enormous AI governance exposure, purely from employees [using consumer AI tools with company data](https://colchix.com/blog/what-is-shadow-ai). Company size or technical sophistication has nothing to do with which category of risk applies; usage pattern does. ### Where the two genuinely overlap They're not unrelated. Organizations that build or fine-tune their own AI products need both: security to protect the model itself from adversarial misuse, and governance to control what data reaches it and what happens to the outputs. A company running a customer-facing AI chatbot, for instance, needs security controls against prompt injection and governance controls over what data that chatbot can access and log. But most regulated enterprises today aren't building AI products. ### Frequently asked questions #### What is the difference between AI governance and AI security? AI security asks whether an AI system is safe from attack: jailbreaks, manipulation, adversarial inputs. AI governance asks what happens to the organization's data when employees use any AI system, and whether that control can be proven. AI security protects the model from the world; AI governance protects the organization from how any model gets used. #### Does an AI security tool cover employees using ChatGPT? Not necessarily. Red-teaming platforms and prompt-injection defences protect AI systems your organization has built or deployed. An employee pasting a client contract into public ChatGPT isn't an attack on a model; it's an ungoverned data flow to a model your organization doesn't control at all. #### When does an organization need both? When it builds or fine-tunes its own AI products. A company running a customer-facing AI chatbot, for instance, needs security controls against prompt injection and governance controls over what data the chatbot can access and log. --- Source: https://colchix.com/blog/ai-governance-vs-ai-security ## What Is AI Governance? A Practical Definition for Regulated Enterprises > AI governance isn't a policy document. It's the technical ability to see, control, and prove what your organization's AI systems actually do. Here's what that means in practice. Colchix Team & Gianni Valerio, CEO · Published 12 August 2026 · Updated 12 October 2026 · AI Governance · 4 min read **In short:** AI governance is the ability to see which AI systems your organization actually uses, control what data reaches them, and prove both to a regulator on demand. It rests on three technical capabilities applied to every AI tool, approved or not: visibility, control and evidence. A policy states intent; runtime governance is the infrastructure that makes it real. AI governance is the ability to see which AI systems your organization actually uses, control what data reaches them, and prove both of those things to a regulator on demand. Not a policy. Not a training session. A technical capability. Most companies don't have it. They have a document. ### The definition everyone gets wrong Search "AI governance" and you'll find a hundred variations of the same vague sentence: "a framework of policies and practices to ensure responsible AI use." True, and useless. It tells you nothing about what governance actually requires you to build. Here's the version that holds up in an audit: > **AI governance is the combination of three technical capabilities — visibility, control, and evidence — applied to every AI system your organization touches, whether you approved it or not.** - **Visibility**: knowing which AI tools are in use, by whom, with what data — [including the ones IT never approved](https://colchix.com/blog/what-is-shadow-ai). - **Control**: the ability to intervene before sensitive data reaches an external model, not after. - **Evidence**: logs and records that prove the first two points happened, in a format a regulator or auditor will accept. Remove any one of the three and you don't have governance. You have an intention. ### Why "we have a policy" isn't governance A policy is a sentence in a PDF that says employees shouldn't paste client data into ChatGPT. It has never once stopped an employee from doing exactly that at 4:47pm on a Friday, under deadline, with no bad intent — just work that needed to get done. This isn't a hypothetical. Internal studies on shadow IT consistently show the gap between written policy and actual behavior is enormous, and AI tools have made it worse, not better, because the barrier to use dropped to zero. No install, no approval, no IT ticket — just a browser tab. > Governance that lives only on paper fails the moment it meets a real deadline. Governance that lives at the infrastructure level doesn't need the employee to remember the rule, because the rule enforces itself. ### Governance vs. security: not the same thing [These get conflated constantly](https://colchix.com/blog/ai-governance-vs-ai-security), and the confusion costs companies real time in vendor selection. **AI security** asks: is this model safe from attack, manipulation, or jailbreaking? It protects the model itself, and it matters most for organizations building or fine-tuning their own models. **AI governance** asks a different question: what happens to our data when our employees use any model, ours or someone else's? It's not about hardening a model — it's about controlling what flows in and out of it, and being able to prove that control existed. A company can have excellent AI security and zero AI governance. It happens constantly: a well-secured internal AI product, sitting next to a workforce that pastes contract drafts into public ChatGPT with no oversight at all. ### What regulated enterprises specifically need to govern If you're in fintech, banking, insurance, healthcare, or manufacturing operating in Europe, governance isn't optional reading — it's already a legal obligation layered across multiple frameworks that don't fully overlap: - **GDPR** — [governs any AI use that touches personal data](https://colchix.com/blog/ai-act-vs-gdpr), regardless of which model processes it - **The EU AI Act** — general-purpose obligations under the Act, including Article 4's AI literacy requirement (in force since February 2025), apply regardless of sector; the high-risk Annex III obligations, meanwhile, [were pushed to December 2027](https://colchix.com/blog/ai-act-enforcement-timeline) following the Digital Omnibus proposal (May 2026) — a detail that gets lost in most vendor marketing still running August 2026 deadline messaging - **NIS2** — brings AI tooling into scope as part of supply-chain and operational risk, particularly relevant if AI tools touch systems classified as essential or important entities - **DORA** — for financial institutions, extends operational resilience requirements to AI-driven processes None of these frameworks tell you how to build governance. They tell you what you'll be asked to prove exists, after the fact, when something goes wrong. ### The part most companies skip: runtime governance Most AI governance efforts stop at documentation — an inventory of approved tools, a signed acceptable-use policy, maybe a quarterly review. [That's governance on paper](https://colchix.com/blog/runtime-ai-governance). It answers "what did we intend?" **Runtime governance** answers a harder question: "what actually happened, as it happened?" It means intercepting AI usage as it occurs — not reviewing it a quarter later — and applying controls (visibility into shadow tool use, protection of sensitive data before it leaves your perimeter, logging that survives an audit) in real time, without requiring employees to change how they work. > This is the gap between having a governance policy and having governance. One is a statement of intent. The other is infrastructure. ### What good governance actually looks like in practice Not a binder. Three things running continuously, at the same time: 1. A live inventory of every AI tool in use across the organization — approved and unapproved — updated automatically, not manually maintained by IT once a quarter. 2. A technical control that prevents sensitive data from reaching an external model in readable form, before it happens, not a policy asking employees to remember not to. 3. [An audit trail](https://colchix.com/blog/ai-audit-trail) — who used what tool, with what data, when — retained and structured well enough that when a DPO or regulator asks for evidence, the answer is a report, not a scramble. If your organization can't produce all three today, on demand, your AI governance still has a runtime gap. ### Frequently asked questions #### What is AI governance? AI governance is the combination of three technical capabilities applied to every AI system your organization touches, approved or not: visibility into which AI tools are in use, by whom and with what data; control, to intervene before sensitive data reaches an external model; and evidence, records that prove both in a form a regulator or auditor will accept. #### Is an AI usage policy the same as AI governance? No. A policy is a statement of intent: it tells employees not to paste client data into AI tools, but it can't stop them under deadline. Governance that lives at the infrastructure level doesn't need the employee to remember the rule, because the rule enforces itself. #### Which regulations make AI governance an obligation in Europe? For regulated European enterprises it already is one, across frameworks that don't fully overlap: GDPR for any AI use touching personal data; the EU AI Act, including Article 4's AI literacy requirement; NIS2, which brings AI tooling into supply-chain and operational risk; and DORA, which extends operational resilience requirements to AI-driven processes in financial institutions. #### What does good AI governance look like in practice? Three things running continuously: a live inventory of every AI tool in use, approved and unapproved, updated automatically; a technical control that stops sensitive data reaching an external model in readable form; and an audit trail of who used which tool, with what data and when, structured well enough to answer a DPO or regulator with a report. --- Source: https://colchix.com/blog/what-is-ai-governance ## What Is Shadow AI? Risks, Examples and Enterprise Mitigation > Shadow AI is every AI tool your employees use that IT never approved — and it's already inside your organization. Here's what it looks like, why it's growing, and how to see it. Colchix Team & Gianni Valerio, CEO · Published 11 August 2026 · Updated 12 October 2026 · Shadow AI · 4 min read **In short:** Shadow AI is any AI tool an employee uses for work that IT never approved, configured or knows exists. It spreads faster than shadow IT because there's nothing to install, and it's usually the best people working efficiently. Blocking only removes visibility, as employees route around it; what reduces the risk is visibility, protection at the point of use and continuous evidence. Shadow AI is any AI tool an employee uses for work that IT never approved, never configured, and doesn't know exists. Not a hypothetical category. It's running inside your organization right now, on devices you issued, during work hours, done by people who aren't trying to cause a problem. It's the fastest-growing blind spot in enterprise IT, and it didn't exist in this form three years ago. ### Why shadow AI is different from shadow IT Shadow IT — employees using unapproved software, from Dropbox to Trello — has existed for two decades. Companies built entire security categories around finding and controlling it. Shadow AI moves faster, for one structural reason: there's nothing to install. Shadow IT required downloading an app, creating an account, sometimes even a company card to pay for it — friction that gave IT teams a chance to notice. Shadow AI requires opening a browser tab. ChatGPT, Claude, Gemini, Perplexity — all free tier, all accessible in under ten seconds, often poorly understood by security controls that were designed for traditional applications and file transfers, rather than AI-specific usage and prompt-level data flows. That's the core problem: most enterprise security stacks were architected to catch app installs and file transfers, not conversational queries typed into a browser. Shadow AI slips through a gap that wasn't there when the tooling was designed. ### What shadow AI actually looks like inside a company Not a rogue employee doing something reckless. The opposite — it's usually your best people, working efficiently. - A sales rep pastes a prospect's contract terms into ChatGPT to draft a counter-proposal faster. - An engineer copies a proprietary code snippet into Claude to debug a production issue at 6pm. - An HR manager uploads anonymized-in-their-mind employee performance data into Gemini to draft review summaries — except the data isn't actually anonymized. - A finance analyst feeds unreleased quarterly figures into Perplexity to check how a competitor phrased something similar. None of these people think they're doing anything wrong. They're solving a problem, fast, with a tool that's sitting right there. That's exactly what makes shadow AI hard to stop with policy alone — the behavior isn't malicious, it's rational, and it happens under normal work pressure, not edge cases. ### Why it's a bigger risk than most companies assume **No audit trail.** When sensitive data reaches an external AI service, it may trigger international data-transfer requirements under GDPR Chapter V — often without the organization having assessed the transfer, because it may not even know the AI tool was used. You cannot assess a data flow you don't know exists. **Confidentiality breach exposure.** NDAs, client contracts, and supplier agreements routinely include confidentiality clauses that don't carve out "unless an employee pastes it into a chatbot." Legal teams are only beginning to catch up to what this means in practice. **It compounds, not stays static.** Shadow AI usage grows every quarter a company doesn't address it, because more tools launch, more employees discover them, and the behavior normalizes across teams that watch colleagues do it without consequence. ### Why blocking doesn't work The obvious-seeming fix — block ChatGPT and its peers at the network level — fails for a reason most IT teams discover only after trying it: employees route around it. Personal devices, mobile data, browser extensions built specifically to bypass corporate filters. Blocking doesn't eliminate the behavior, it just removes your visibility into it — the worst possible outcome, because now the same risk exists with zero logging at all. There's also a business cost to blocking that's easy to underweight: these tools genuinely make people faster. An outright ban pushes the most productive employees toward the highest-friction workaround, while doing nothing to the majority who'll simply find another tab. Shadow AI is not fundamentally an employee problem. It's an infrastructure problem. Employees will use the tools that help them work faster. The governance layer has to make that behavior safe, visible and auditable — without asking people to stop being productive. ### What actually reduces shadow AI risk Not policy. Not training sessions, though those help marginally. Three things, working together: 1. **Visibility first.** [You can't govern what you can't see](https://colchix.com/blog/shadow-ai-detection). Before anything else, an organization needs an accurate, continuously updated picture of which AI tools are actually in use — not the list IT approved, the list employees are actually opening. 2. **Protection at the point of use.** Real-time interception that [tokenizes or masks sensitive data](https://colchix.com/blog/tokenization-vs-redaction) before it reaches an external model — not a policy asking someone to remember not to paste something, a technical control that acts regardless of whether they remember. 3. **Evidence, continuously.** [A log of what happened](https://colchix.com/blog/ai-audit-trail) — who, what tool, what category of data — retained in a form that holds up when a DPO or regulator asks for it. This is the same three-part structure that [defines AI governance more broadly](https://colchix.com/blog/what-is-ai-governance) — shadow AI is simply the sharpest, most immediate example of what happens when an organization has none of the three. ### The question every security leader is asking wrong Most conversations about shadow AI start with "how big is our exposure" — as if it's a number to estimate. It isn't. It's a visibility problem to solve. The question isn't "do we have a shadow AI problem." Any organization with employees and internet access does, by definition. The only real question is whether anyone can currently see it. ### Frequently asked questions #### What is shadow AI? Shadow AI is any AI tool an employee uses for work that IT never approved, never configured and doesn't know exists, such as a sales rep pasting contract terms into ChatGPT or an engineer debugging proprietary code in Claude. It's usually not reckless behavior but people solving problems fast with the tool at hand. #### How is shadow AI different from shadow IT? Shadow IT needed an install, an account or a company card: friction that gave IT a chance to notice. Shadow AI needs a browser tab. Security stacks built to catch app installs and file transfers often miss conversational queries typed into a browser. #### Why doesn't blocking ChatGPT stop shadow AI? Employees route around it with personal devices, mobile data and browser extensions. Blocking doesn't remove the behavior, only your visibility into it, leaving the same risk with no logging at all, and it pushes productive people towards higher-friction workarounds. #### How do you reduce shadow AI risk? With three things working together: visibility into which AI tools are actually in use; protection at the point of use that tokenizes or masks sensitive data before it reaches an external model; and continuous evidence of who used which tool with what category of data. --- Source: https://colchix.com/blog/what-is-shadow-ai ## AI Act vs GDPR: What Actually Changes for Enterprises > GDPR and the AI Act aren't the same law wearing a different name. Here's exactly where they overlap, where they diverge, and what that means for your compliance program. Colchix Team & Gianni Valerio, CEO · Published 10 August 2026 · Updated 12 October 2026 · AI Act & Regulation · 5 min read **In short:** GDPR asks questions about personal data; the EU AI Act asks questions about AI systems. Both can apply to the same AI activity at once, and complying with one doesn't satisfy the other. Article 4 (AI literacy) and Article 50 (transparency) already apply, while the Annex III high-risk rules now apply from 2 December 2027. Both frameworks converge on accountability, so one evidence layer can support both. GDPR and the AI Act are not the same regulation with a new name attached. GDPR governs personal data — what you collect, why, and what you do with it. The AI Act governs systems — what an AI system does, how much oversight it needs, and what you have to prove about how it behaves. A company can be fully GDPR-compliant and still be exposed under the AI Act. Most compliance programs built before 2024 don't yet reflect that. ### The core distinction, in one sentence **GDPR asks questions about data. The AI Act asks questions about systems.** If your organization processes personal data through an AI tool, both laws apply simultaneously, to different parts of the same activity — and they don't automatically satisfy each other. A GDPR-compliant data processing agreement with a vendor says nothing about whether the AI system itself meets the AI Act's transparency or oversight requirements. | | GDPR | EU AI Act | | --- | --- | --- | | Primary focus | Personal data | AI systems | | Triggered by | Processing personal data | Developing, providing or deploying AI within scope | | Core concern | Lawful, transparent and secure data processing | Risk, transparency, oversight and accountability | | Applies without personal data? | No | Yes | | Evidence | Accountability & processing records | Documentation, logging & oversight where applicable | | Can both apply? | Yes — simultaneously | Yes — simultaneously | ### Where GDPR still does the heavy lifting For most AI use cases inside a regulated enterprise today, GDPR remains the more immediately enforceable framework, because it's mature, well-understood, and has been tested in courts and by data protection authorities for years. GDPR governs an AI interaction the moment personal data is involved — a customer's name in a support ticket, an employee's performance data in an HR tool, a client's contract details pasted into a drafting assistant. Article 25 (privacy by design) and Article 30 (records of processing) are the two provisions that matter most in practice: they require that data protection is built into the process, not bolted on, and that organizations can produce a record of what processing actually took place. This is where the disconnect between policy and reality shows up first. An organization can have a GDPR-compliant privacy policy and a signed DPA with every AI vendor it officially uses, and still have zero visibility into what happens when an employee pastes personal data into [a consumer AI tool nobody approved](https://colchix.com/blog/what-is-shadow-ai). The policy is compliant. The behavior isn't covered by it. ### Where the AI Act adds a genuinely new layer The AI Act doesn't replace GDPR's focus on personal data — it adds obligations that are independent of whether personal data is involved at all. A system can be entirely GDPR-compliant (no personal data touched) and still fall under AI Act obligations, because the AI Act cares about the system's function and risk classification, not just the data flowing through it. Two obligations matter most right now for enterprises: **Article 4 — AI literacy.** Applicable since February 2025, this requires providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy among relevant staff, taking into account their technical knowledge, experience and the context in which the systems are used. **Article 50 — transparency.** Applicable since 2 August 2026, Article 50 introduces specific transparency obligations for certain AI systems and AI-generated content — including informing people when they are interacting with AI, and disclosure requirements for deepfakes and certain AI-generated public-interest content. What's not currently in force, and gets misrepresented constantly in vendor marketing: the high-risk system obligations under Annex III. Following the 2026 AI Omnibus, application of the high-risk rules for Annex III systems has been extended to 2 December 2027, while rules for high-risk AI embedded in regulated products under Annex I apply from 2 August 2028. If you're evaluating vendors and one is running urgent "AI Act deadline" messaging tied to August 2026 for Annex III-scope obligations, that's worth double-checking against [the current timeline](https://colchix.com/blog/ai-act-enforcement-timeline) before it shapes a budget decision. Source: [European Commission — AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) · [Guidelines on transparency obligations (Article 50)](https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems) ### The overlap that actually matters: accountability Both frameworks converge on the same underlying demand, expressed differently: you must be able to show, on request, what your systems did and why. GDPR calls this accountability (Article 5(2)) and demonstrable compliance. The AI Act calls it technical documentation, logging, and human oversight. Different vocabulary, same operational requirement — a real-time record of AI activity that holds up when someone asks for it, not a reconstruction assembled under pressure after an incident. This is the practical reason treating GDPR and the AI Act as two separate compliance projects is inefficient. The underlying evidence infrastructure can support both frameworks. [A technical record of which AI system was used](https://colchix.com/blog/ai-audit-trail), when, under whose authority, and with which categories of data can support GDPR accountability while also contributing to AI Act logging, transparency, and oversight requirements where applicable. ### What this means for a compliance program in practice A few concrete implications, if you're mapping this to an actual program rather than reading it as theory: - **A DPA with your AI vendor covers GDPR obligations for that specific tool. It says nothing about shadow AI use of tools you don't have a DPA with** — which is most of what employees actually use day to day. - **AI literacy (Article 4) is a current, active obligation**, not a 2027 concern — if your organization hasn't documented how it's meeting this, that's a gap that exists today, independent of the Annex III delay. - **Evidence infrastructure can serve both frameworks at once.** A log that captures which employee used which AI tool, with what category of data, and when, contributes to GDPR processing-record evidence and AI Act oversight documentation alike. - **"We have a DPA" is not the same claim as "we're AI Act compliant."** They're answers to different questions, and a DPO who can only answer the first one has a real, current gap — not a hypothetical future one. ### The bottom line GDPR tells you how to handle personal data responsibly. The AI Act tells you how to operate AI systems responsibly. An enterprise using AI at any scale is subject to both, and building compliance infrastructure for one without the other leaves a real gap — one regulators are increasingly positioned to notice, given how much overlap exists between what both frameworks actually ask an organization to prove. ### Frequently asked questions #### What is the difference between GDPR and the EU AI Act? GDPR governs personal data: what you collect, why and what you do with it. The AI Act governs AI systems: what a system does, how much oversight it needs and what you have to prove about how it behaves. The AI Act can apply even when no personal data is involved. #### Can GDPR and the AI Act apply at the same time? Yes. If your organization processes personal data through an AI tool, both apply simultaneously to different parts of the same activity, and they don't automatically satisfy each other. A GDPR-compliant data processing agreement says nothing about whether the AI system meets the AI Act's transparency or oversight requirements. #### Which AI Act obligations already apply to enterprises? Article 4 on AI literacy has applied since February 2025, and Article 50's transparency obligations since 2 August 2026. Following the 2026 AI Omnibus, the high-risk rules for Annex III systems apply from 2 December 2027, and those for high-risk AI in regulated products under Annex I from 2 August 2028. #### Can one evidence layer support both frameworks? Yes. Both converge on accountability: being able to show what your systems did and why. A technical record of which AI system was used, when, under whose authority and with which categories of data can support GDPR accountability while also contributing to AI Act logging, transparency and oversight where applicable. --- Source: https://colchix.com/blog/ai-act-vs-gdpr ## Why Redaction Isn't Enough: Tokenization vs Destructive Masking > Redaction deletes data and breaks context. Tokenization replaces it with something reversible. The difference determines whether your AI governance layer actually works. Colchix Team & Gianni Valerio, CEO · Published 9 August 2026 · Updated 12 October 2026 · Data Protection · 4 min read **In short:** Redaction protects sensitive data by destroying it, which breaks the structure an AI model needs to give a useful answer. Tokenization replaces each sensitive value with a consistent, reversible token before the query leaves the perimeter, then restores the originals in the response. It is the better default for most enterprise AI use, with one honest limit: tasks that need an entity's real identity, such as sanctions screening. Two approaches exist for [keeping sensitive data out of an AI model's hands](https://colchix.com/blog/ai-data-leakage): destroy it, or disguise it reversibly. Most vendors in this space still default to the first. It's the wrong default, and the reason comes down to what happens to the response you get back, not just the query you send. ### What redaction actually does Redaction — sometimes called destructive masking — removes sensitive data before it reaches an AI model, typically replacing it with a blank, a generic placeholder, or nothing at all. `[REDACTED]`. \*\*\*. Gone. It solves half the problem. The sensitive value never reaches the external model, which is correct. But redaction has a structural flaw that only shows up once you look at what the AI is supposed to do with the input: it destroys the entity-level structure the model needs to give you a genuinely useful answer. Ask an AI to summarize a contract, and redaction produces something like: "The NDA between `[REDACTED]` and `[REDACTED]`, signed `[REDACTED]`, covers IP transfer valued at `[REDACTED]`." Technically readable, but every placeholder is indistinguishable from every other — the model has no way to know whether the two `[REDACTED]` tags refer to the same entity mentioned twice, or two different ones. ### What tokenization does differently Tokenization replaces each sensitive value with a structured, reversible token — `[ORG_001]`, `[PII_PERSON_001]`, `[DATE_001]` — before the query leaves your perimeter. The AI model receives a structurally coherent query: relationships, entity types and surrounding context remain intact, while the sensitive values themselves are replaced with consistent placeholders. Tokenization solves the consistency problem redaction can't: "`[ORG_001]` acquired `[ORG_002]`. `[PERSON_001]` will retain control of `[ORG_002]`." The model knows ORG\_002 in the second sentence is the same entity as in the first, that PERSON\_001 is a person, that a specific relationship exists between them — structure and consistency preserved, real-world identity removed. When the response comes back, the tokens are resolved to the original values before the employee sees the answer. This is the distinction that matters: **redaction removes information permanently. Tokenization removes it temporarily, in a way that can be put back.** ### Why "no training on your data" doesn't solve this either A common alternative pitch in this space is contractual: a vendor promises your data won't be used to train their models. It's a real commitment, and it's worth having in a contract. But it answers a different question than the one that matters for compliance. A no-training commitment is a contractual safeguard. Tokenization is a technical control. The two solve different problems: one asks you to trust what happens to sensitive data after transfer. The other is designed to prevent the sensitive value from being transferred in readable form in the first place. If your evidence for a regulator is "we have a no-training clause in a vendor agreement," you're relying on a contractual promise, not a demonstrable technical control — and those are [treated very differently in an audit](https://colchix.com/blog/ai-audit-trail). Tokenization doesn't depend on trusting a vendor's training practices, because the sensitive data never reaches them in readable form to begin with. The original values stay inside your perimeter the entire time. There's nothing external to trust. ### The trade-off tokenization doesn't fully solve Being direct about a limitation matters more than pretending one doesn't exist: tokenization has a real constraint on entity-dependent tasks. If an employee asks an AI to cross-reference a company name against a sanctions list, or to research a specific organization's public reputation, tokenizing that company name into `[ORG_001]` removes the exact information the model needs to do the lookup. The model can't check a name it never saw. For these specific use cases — sanctions screening, company or individual research, anything requiring the model to act on the real-world identity of an entity — tokenization creates a genuine limitation that redaction shares, and that no masking approach fully resolves without exposing the underlying identity at some point in the process. The honest framing: tokenization is the right default for the overwhelming majority of enterprise AI use — summarization, drafting, analysis, code review, internal Q&A — where the model needs to reason about structure and relationships, not verify real-world identity. For the narrower set of tasks that require identity verification against external sources, that step needs a separate, deliberate process — not a blind spot papered over by a vendor claiming their masking handles everything. ### What this means when evaluating a vendor A few direct questions worth asking [any AI governance vendor](https://colchix.com/blog/best-ai-governance-platforms-europe-2026), based on this distinction: - **Is masking reversible or destructive?** If the answer is destructive, ask how the vendor handles tasks that need context preserved — summarization, translation, analysis — because redaction and those tasks are in tension by design. - **Where does the original data live during processing?** If sensitive values ever leave your controlled perimeter — even briefly, even to the vendor's own infrastructure — that's a transfer that needs its own compliance assessment, tokenization or not. - **What happens with entity-dependent tasks?** A vendor who claims their masking has no limitations for tasks requiring real identity resolution is either overselling or hasn't thought through the edge case. The honest answer acknowledges the constraint. ### The bottom line Redaction protects data by destroying information. Tokenization protects data by making it temporarily unreadable to everyone except the system that can put it back. For any AI task that depends on the model actually understanding what it's working with — which is most of them — that difference is the difference between a tool that works and one that technically complies while quietly producing worse output. ### Frequently asked questions #### What is the difference between redaction and tokenization? Redaction removes sensitive data permanently, usually replacing it with a blank or a generic placeholder. Tokenization replaces each sensitive value with a structured, reversible token, such as [ORG_001], before the query leaves your perimeter, and resolves the tokens back to the original values before the employee sees the answer. #### Why does redaction produce worse AI answers? Every redacted placeholder looks like every other, so the model can't tell whether two [REDACTED] tags refer to the same entity or to two different ones. Tokenization keeps relationships, entity types and context intact, so the model can still reason about the structure of the text. #### Is a no-training clause in a vendor contract enough? It's a real commitment worth having, but it's a contractual safeguard, not a technical control: it asks you to trust what happens to sensitive data after transfer. Tokenization is designed to stop the sensitive value from being transferred in readable form at all, and the two are treated very differently in an audit. #### When doesn't tokenization work? On entity-dependent tasks, such as checking a company against a sanctions list or researching a specific organization's reputation, tokenizing the name removes exactly what the model needs. Those tasks need a separate, deliberate process; for summarization, drafting, analysis, code review and internal Q&A, tokenization is the right default. --- Source: https://colchix.com/blog/tokenization-vs-redaction ## Runtime AI Governance: Why Policies on Paper Don't Stop Anyone > A signed AI usage policy has never once stopped an employee mid-deadline. Runtime governance is the difference between intending to control AI use and actually controlling it. Colchix Team & Gianni Valerio, CEO · Published 8 August 2026 · Updated 12 October 2026 · Runtime Governance · 5 min read **In short:** An AI usage policy describes what should happen; runtime governance controls what actually does, at the moment AI is used. It takes three capabilities working together: interception of each AI interaction as it happens, real-time protection of sensitive data before it leaves the organization, and continuous evidence of what happened, without asking employees to change how they work. Every organization with an AI usage policy has the same evidence problem: the policy describes what should happen, and nothing describes what actually did. Runtime governance closes that gap — not by writing a better policy, but by moving control from a document to the moment the AI system is actually used. ### The policy was never the control [An AI acceptable-use policy](https://colchix.com/blog/what-is-ai-governance) typically says something like: employees must not input confidential, personal, or proprietary data into external AI tools without approval. Reasonable. Almost universally adopted. And almost universally ignored the moment it collides with a real deadline, because a policy has no mechanism to intervene — it can only ask, after the fact, why someone didn't follow it. This isn't a training problem. Even employees who know the policy exists can violate it under normal work pressure, because in the moment, finishing the task is immediate while the policy feels abstract. > **A policy governs intention. Runtime governance governs the event itself, as it happens.** ### What "runtime" actually means here Runtime governance means the control operates at the moment of use — when the employee opens the tool, types the query, and hits send — not at a scheduled review weeks or months later. Concretely, that's the difference between two very different governance postures: **Periodic governance** — a quarterly audit of approved AI tool usage, an annual policy re-signature, a survey asking employees to self-report what tools they use. All useful for documentation. None of it catches anything happening in real time, and all of it depends on people accurately reporting their own policy violations. **Runtime governance** — the AI interaction is intercepted, evaluated, and governed as it occurs. Sensitive data is protected before it leaves the organization's perimeter, regardless of which tool the employee opened or whether it was on an approved list. The control doesn't need the employee to remember a rule, because the rule is enforced structurally, at the point of use. Only one of these actually prevents the thing the policy was written to prevent. ### Why periodic review structurally can't catch what runtime governance catches The gap isn't a matter of frequency — reviewing more often doesn't fix it. It's a matter of what a review can see in the first place. A quarterly access review can confirm which employees have accounts on approved tools. It cannot tell you what an employee pasted into ChatGPT last Tuesday on their personal account, because that event left no record anywhere a quarterly review would look. The absence of evidence isn't evidence of absence — it's evidence that nothing was watching at the time it mattered. This is the same failure mode as trying to audit a data breach that happened three months before anyone noticed: the damage, if any, already occurred. Runtime governance doesn't just catch violations faster. It changes what's structurally possible to happen in the first place, because the control sits between the employee and the external model, not after both. ### The three things runtime governance requires This isn't a single feature — it's three capabilities operating continuously and together, at the moment of use, not the moment of review: 1. **Interception.** The system needs to see the AI interaction as it happens — which tool, which employee, what's being sent — not reconstruct it later from logs that may not exist. 2. **Real-time protection.** Sensitive data needs to be handled — [tokenized, masked, blocked](https://colchix.com/blog/tokenization-vs-redaction), whatever the policy requires — before it leaves the organization's control, not flagged for review after it already left. 3. **Continuous evidence.** Relevant AI activity and control events need to be logged with enough context to demonstrate what happened — [building the record automatically](https://colchix.com/blog/ai-audit-trail), without unnecessarily exposing prompt contents or employee data, rather than reconstructing it under pressure when someone asks for it. Remove interception, and you're back to periodic self-reporting. Remove real-time protection, and you're logging violations instead of preventing them. Remove continuous evidence, and you have no way to prove any of it happened, even when it worked exactly as intended. ### Why this matters more for AI than it did for previous technology waves Organizations have lived with imperfect policy enforcement before — most companies never fully controlled what left on a USB drive or got pasted into personal email either. What's different with AI is the combination of frequency and stakes: the barrier to use is now zero (no install, no approval, just a browser tab), the tools improve constantly and expand what employees can do with them, and the categories of data involved — contracts, source code, client records, unreleased financials — sit exactly where a data protection authority or an auditor is most likely to look first. A slow-moving, low-frequency risk tolerates periodic review reasonably well. A high-frequency, high-stakes one doesn't. Every week without runtime controls is another week of ungoverned exposure accumulating, not a static risk being managed. ### What this looks like when it's working Not a dashboard nobody checks. Three things happening simultaneously, invisibly, without requiring the employee to behave differently: - An employee opens ChatGPT and pastes a client contract to draft a summary. The sensitive terms are tokenized before the query leaves the organization's perimeter — the employee gets a complete, accurate summary back, and never even notices the interception happened. - A DPO is asked by a regulator to demonstrate what categories of personal data were processed by AI systems in the last quarter. The answer is a report generated from existing logs, not a scramble to reconstruct events from memory and Slack messages. - IT discovers [three new AI tools appeared in company usage this month that nobody approved](https://colchix.com/blog/shadow-ai-detection) — not through a survey, but because the runtime layer already saw them being used and logged it automatically. None of these require employees to change how they work, remember a policy, or ask permission before using a tool that helps them move faster. That's not incidental — it's the actual design goal. Governance that requires behavior change to work is governance that will eventually fail when it collides with a deadline. Governance that operates at the infrastructure level doesn't have that failure mode. ### The bottom line A policy tells employees what they should do. Runtime governance makes sure the organization can see and control what actually happens, independent of whether anyone read the policy, remembered it, or chose to follow it under pressure. For AI specifically — fast-moving, zero-friction, touching the most sensitive data an organization holds — that distinction isn't a nice-to-have. It's the difference between governance that exists on paper and governance that exists at all. ### Frequently asked questions #### What is runtime AI governance? Runtime AI governance means the control operates at the moment of use, when an employee opens an AI tool, types a query and hits send, rather than at a scheduled review weeks or months later. The AI interaction is intercepted, evaluated and governed as it occurs, so sensitive data is protected before it leaves the organization, whichever tool is used. #### Why isn't an AI acceptable-use policy enough? A policy has no mechanism to intervene: it can only ask, after the fact, why someone didn't follow it. Under normal work pressure, finishing the task feels immediate while the policy feels abstract. A policy governs intention; runtime governance governs the event itself, as it happens. #### Why can't periodic reviews catch the same risks? Reviewing more often doesn't close the gap, because a review can only see what left a record. A quarterly access review can confirm which employees have accounts on approved tools, but not what someone pasted into a personal ChatGPT account last week. Runtime governance sits between the employee and the external model, not after both. #### What does runtime AI governance require? Three capabilities working continuously and together: interception, to see each AI interaction as it happens; real-time protection, to tokenize, mask or block sensitive data before it leaves the organization's control; and continuous evidence, to log AI activity and control events with enough context to demonstrate what happened. --- Source: https://colchix.com/blog/runtime-ai-governance