Skip to content
Back to Blog
AI & Governance

cajeX: The IT Governance Platform That Turns One Technology Review Into Evidence for Every Regulator

Luan ChristensenAugust 27, 202613 min read

If your company has customers in the EU, processes any personal data, or has deployed AI anywhere in your product, you are already answering to more than one regulator. This is not specific to any single industry. GDPR applies to any organisation handling EU personal data. The EU AI Act's transparency obligations apply to any customer-facing AI system, regardless of sector. Most jurisdictions now expect some baseline standard of IT governance and compliance as a condition of doing business at all.

Specific industries add further layers on top of this baseline, not instead of it. Financial services firms carry DORA in addition to GDPR. Operators of essential or important infrastructure carry NIS2 in addition to GDPR. Healthcare organisations carry sector-specific rules in addition to GDPR. If you work in one of these regulated industries, the baseline obligations do not go away because an industry-specific regulation also applies. They stack.

This post walks through what that stacking actually looks like for a technology decision your team makes this week, and what evidence you would need to produce if more than one regulator asked about it on the same day.

A Concrete Example: One Decision, Three Regulators

Say your engineering team decides to add a new third-party AI vendor to handle customer support triage, routing tickets and drafting first-response replies before a human reviews them. It is a routine decision. It probably gets discussed in a sprint planning session and approved by a team lead without an architecture review ever being scheduled.

Here is what that one decision actually has to answer for, depending on where your customers are and what your organisation does:

  • Under GDPR, if the vendor processes any personal data from EU customers, you need a lawful basis for that processing, a data processing agreement with the vendor, and a record of the decision to use them for this purpose.
  • Under the EU AI Act, if the system interacts with customers, Article 50's transparency obligations require that customers be informed they are interacting with an AI system. This obligation was not delayed by the July 2026 Digital Omnibus and applies from 2 August 2026 regardless of whether the vendor's system counts as "high-risk."
  • Under a US state privacy law such as those now in force in at least 20 states, if the vendor processes data from residents of that state, you may have separate disclosure and data-handling obligations that do not map cleanly onto either of the above.
  • If you are a financial services firm subject to DORA, this vendor is now a third-party ICT provider, and Article 8 requires you to identify, classify, and document it as part of your ICT asset inventory, reviewed at least yearly.

One decision. Four separate sets of obligations, from four regulatory regimes that were not written with each other in mind. Most organisations handle this today by hoping someone remembers to check each box separately, in four different places, none of which talk to each other.

A single new AI vendor decision branches into four regulatory obligations: GDPR requires a data processing agreement, the EU AI Act Article 50 requires customer disclosure, a US state privacy law requires separate disclosure, and DORA Article 8 requires ICT asset registration reviewed yearly

Figure 1 — One decision, four regulatory regimes, none of which talk to each other.

What Most Organisations Actually Have When Asked

If a regulator, auditor, or your own board asked next month to see the evidence behind that vendor decision, satisfying all four of these regulations at once, most technology and compliance teams would have to reconstruct it. Someone would search Slack for the original approval conversation. Someone would check whether a data processing agreement was actually signed, and by whom. Someone would try to remember whether the vendor's customer-facing disclosure language was ever reviewed against Article 50. Someone would check whether the vendor even appears on the current ICT asset register, and if so, when it was last reviewed.

This reconstruction usually takes days, sometimes weeks, and the result is inconsistent depending on who does the reconstructing and how much they can remember or find. That is the actual cost of building compliance evidence around each regulation separately: not that the work never gets done, but that it cannot be produced on demand, in one form, when it is actually asked for.

Without a directive model, evidence must be reconstructed by searching Slack, finding agreements, and checking registers, taking days to weeks with inconsistent results. With cajeX, a compliance report is generated the same day from existing reviews

Figure 2 — Reconstruction under pressure versus evidence that already exists.

Setting This Up: What Actually Goes Into the Directive Set

Before any of this evidence can be produced automatically, the underlying rules have to exist as directives, and this is where the setup work actually happens.

A workspace selects the frameworks that apply to it from the Frameworks Library: GDPR, the EU AI Act, the relevant US state privacy laws, and DORA if the organisation is a financial entity. Every workspace also gets a general best-practices baseline regardless of which specific frameworks are selected. Selection is deliberate. cajeX recommends frameworks based on industry and applicability signals, but nothing is inherited automatically.

For each framework, cajeX treats every clause as a question the organisation needs to answer, not a box to tick. GDPR's Article 28, governing the use of data processors, is asking a specific question: how does your organisation ensure a third-party processor only handles personal data under a documented agreement and your instructions. cajeX suggests a directive to answer that question, something like "Third-Party Data Processing Agreement Required Before Vendor Onboarding," and proposes the mapping between that directive and the clause it answers.

The architect does not have to accept this mapping as written. They can adopt it, refine it if the suggested wording does not match how the organisation actually operates, or write a different directive entirely. The same pattern repeats for the EU AI Act's Article 50, which becomes a directive along the lines of "Customer-Facing AI Systems Must Disclose AI Interaction," and for DORA's Article 8, which becomes something like "All Third-Party ICT Providers Must Be Registered and Reviewed Annually." Each mapping carries a rationale the architect can inspect, and a mapping that looks wrong is treated as wrong. The decision to approve it stays with the architect, not the AI.

Once approved, these directives are live. They apply automatically to every future submission, not just the one that prompted the setup. This is the work that happens once, before the vendor decision in the earlier example is ever submitted for review. Every regulatory clause an organisation faces can become one of its architecture directives this way, whether the source is DORA, NIS2, GDPR, the EU AI Act, or an internal standard that has nothing to do with regulation at all.

A four step chain: GDPR Article 28 is the clause, answered by a directive requiring a third party data processing agreement, applied in an AI review, which produces a Nonconformity finding if the agreement is missing

Figure 3 — The clause is the question. The directive is the answer.

Architecture Compliance Tracking: How cajeX Turns This Into One Reviewable Event

With that directive set in place, the same vendor decision is submitted once, as a project or a business case, and reviewed once by the AI co-worker against every active directive that applies to it, regardless of which regulation each directive traces back to.

The output is a set of findings, each one mapped to the specific directive it relates to. If the vendor has no signed data processing agreement, the review generates a Nonconformity against the GDPR Article 28 directive, with a finding stating specifically that no data processing agreement was located for this vendor and that one is required before onboarding proceeds. If the customer-facing disclosure language has not yet been confirmed, the review generates an Observation against the AI Act Article 50 directive, flagged for a human reviewer rather than blocking the decision outright. If the vendor does not yet appear on the ICT asset register, the review generates a Critical finding against the DORA directive, because an unregistered third-party ICT provider is precisely what Article 8 exists to prevent. Every finding carries a severity and a direct link back to the rule it is checking against, so nobody has to remember which regulation asked for what.

When someone does ask, a CISO preparing for a DORA supervisory conversation, an auditor checking AI Act readiness, a board member asking whether the AI vendor decision was properly reviewed, the Framework Compliance Report generates the answer directly from that same evidence: a coverage scorecard, the specific clauses addressed, and the findings that back up every claim, filtered to whichever framework the person asking actually cares about. The GDPR view and the DORA view are drawn from the same underlying review, not rebuilt separately for each audience.

This is the practical difference between the two ways of working described earlier. One vendor decision, reviewed once, produces evidence that can answer four different regulators without four different reconstruction efforts.

A Second Example: The Same Model, a Different Kind of Decision

The vendor scenario above is one kind of decision. To show this is not specific to AI vendors, here is a structurally different one: your infrastructure team decides to consolidate customer data storage onto a single cloud provider's new region, for cost and latency reasons, a decision that has nothing to do with AI at all.

This decision triggers a different set of obligations than the first example did. Under GDPR's Chapter V, if the new region moves data to a country without an adequacy decision, a valid transfer mechanism such as Standard Contractual Clauses has to be in place before the migration proceeds. Under NIS2's Article 21(2)(d), supply chain security is one of the ten mandatory risk-management measures, meaning the security practices of that cloud provider are now part of your own risk assessment, not just theirs. Under DORA's Article 29, if the provider is one of the 19 hyperscalers and infrastructure firms the EU designated as Critical ICT Third-Party Providers in November 2025, and consolidating onto them increases your dependency on a single, less substitutable provider, you are required to assess and document that concentration risk before the arrangement is finalised, not after.

None of these are the same obligations the AI vendor example triggered. But the underlying model does not change. The directive set already includes GDPR, NIS2, and DORA directives derived the same way as before, clause by clause. The same review pipeline evaluates this infrastructure decision against all of them in one pass. A Critical finding against the DORA Article 29 directive would state specifically that the migration increases reliance on a provider already designated as a Critical ICT Third-Party Provider and that a documented concentration risk assessment is required before proceeding. The Framework Compliance Report shows this finding under the DORA view and, separately, whatever the NIS2 supply chain finding looks like under the NIS2 view, generated from the same underlying review.

The value of a regulation-agnostic directive model is not that it handles the AI vendor scenario well. It is that it handles this scenario, and whatever the next unrelated technology decision turns out to be, with the same setup, the same review, and the same reporting, without anyone having to build a new process for each new kind of decision that comes up.

An AI vendor decision and a cloud region decision both feed into one directive set and one AI review, producing a Framework Compliance Report that generates separate GDPR, DORA, and NIS2 views from the same evidence

Figure 4 — Two unrelated decisions. The same model. Different regulators, same evidence.

Why This Gets Harder, Not Easier, From Here

The scenario above is already common today. It is going to become the default, not the exception. Laws covering data protection, cybersecurity, and AI across the US, Canada, the EU, and China have grown 400% since 2016, and over 80% of the global population is now covered by some form of data privacy regulation. Within the US alone, at least 20 states now have comprehensive privacy laws, each with its own scope and thresholds.

The EU AI Act's own July 2026 deadline shift is a useful data point here, not because the AI Act itself is unusual, but because it shows how quickly even a single regulation's shape can change. Organisations that had built a compliance programme specifically scoped to the original 2 August 2026 high-risk deadline are now working out how much of that effort still applies, now that most of it moved to December 2027. Article 50 and the AI literacy duty under Article 4 were untouched and still apply on the original date. The organisations least disrupted by this change are the ones whose underlying evidence, which decisions were reviewed, against which rules, with what findings, was never specific to the AI Act's original deadline in the first place.

Analysis of 2026 enforcement priorities from the European Data Protection Board and national authorities including the CNIL confirms where this is heading: organisations are increasingly assessed on their ability to demonstrate control over data, technology, and risk, not on formal compliance alone. That is the same underlying question behind GDPR, DORA, NIS2, every US state privacy law, and the AI Act. Building the answer to that question once, in a form that works regardless of which regulator is asking, is what mature enterprise architecture governance looks like today. Rebuilding a separate answer for each regulation as it arrives does not.

What This Means for Your Team

If your organisation is currently tracking compliance for more than one regulation in more than one place, spreadsheets, shared drives, whichever team happens to own that regulation, this is worth a direct look at your specific situation. The Frameworks Library covers over 300 frameworks including GDPR, DORA, NIS2, the EU AI Act, and a growing list of US state privacy laws, each pre-mapped into directives ready for review. If your team is new to cajeX, Getting Started with cajeX walks through the four-step approach from knowledge base to governed directives.

Sources

Ready to transform your architecture governance?

cajeX brings AI-powered reviews, knowledge management, and directive lifecycle management to your enterprise architecture team.

Start FreeMore Articles