ENGINEERING THE NEXT GENERATION

Logo
Home/Blog/What Does AI Governance Cost When You Connect Legacy Systems?
AI GovernanceLegacy SystemsEnterprise AICost AnalysisRisk Management

What Does AI Governance Cost When You Connect Legacy Systems?

November 6, 2026
Translucent control layer of checkpoints sitting between an AI core and older server racks
Governance is a set of controls between the AI and your systems. Its cost follows what the AI is allowed to do.

TL;DR & Quick Summary

There's no reliable market price for AI governance, because published figures cover very different scopes. Instead, estimate it from the controls you need, and those depend on what the AI is allowed to do.

As a planning guide (our own ranges, not market benchmarks):

What the AI can do Governance adds to the build Ongoing effort
Read-only assistant, one system About 15–25% A few hours a month
Read-only, several systems or sensitive data About 20–35% Regular access and log reviews
Writes to systems, with approvals About 30–50% Weekly review at first, then monthly
  • Biggest cost driver: the gaps in the legacy system, such as shared accounts, coarse permissions and missing audit logs

  • Cheapest control: not giving the AI the capability in the first place

  • Reuse what you have: existing identity, logging and approval systems cut cost

  • Key Takeaway: Decide what the AI may do, then size the controls to that. Governance bought before that decision is either too much or too little.

  • Get Started: Want a governance estimate for your integration? Schedule a strategy call with Cogniq AI or see our AI integration services.


Why Published Numbers Won't Help Much

Search for AI governance costs and you'll find figures from tens of thousands of dollars to several million a year. They aren't necessarily wrong. They're measuring different things:

  • Tool costs only, versus tools plus staff
  • One system, versus a company-wide programme
  • A startup, versus a regulated multinational

A budget for an enterprise-wide governance programme tells you almost nothing about the cost of governing one assistant connected to one ERP. So compare scope before you compare numbers, and build your own estimate.

What Governance Actually Means Here

For a legacy integration, governance isn't a policy document. It's a set of working controls between the AI and your systems. The NIST AI Risk Management Framework is a useful way to structure them, and these are the ones that take real engineering:

  1. Identity and access: the AI sees only what the requesting user may see
  2. Logging: inputs, outputs, data used and actions taken, tied to a user
  3. Approvals: a person signs off high-impact actions
  4. Limits: hard caps on what can be changed, by how much and how often
  5. Testing: a test set run before every release
  6. Monitoring: failure rates, unusual activity and cost
  7. Stop and reverse: a way to switch the AI off and undo its actions
  8. Ownership: a named person accountable for its behaviour

Not every system needs all of these at full strength. A read-only assistant needs no approval workflow. An agent that changes customer records needs every item above.

Why Legacy Systems Cost More to Govern

Modern platforms supply much of this already. Older systems often don't:

Gap in the legacy system What it means for the AI layer
Shared accounts Activity can't be tied to a person, so you must build per-user identity above the system
Coarse permissions Access rules must be rebuilt outside the system and kept in sync
Rules inside the application Direct database access skips business rules, so writes need a controlled service
Missing audit logs You must log everything yourself, on your side of the connection
No test environment A safe copy must be created before testing

This is why a governance estimate should begin with an audit of the legacy system, not a list of tools. It's also why the access route you choose affects governance cost as much as build cost.

A Worked Estimate

For illustration, take the read-only assistant from our legacy integration cost guide: a support assistant reading from a fifteen-year-old ERP, about 720 hours to build. The ERP uses shared accounts and has no usable audit log. Here are the governance tasks:

Control Hours
Map ERP roles to user identities; filter data by plant and role 60
Log questions, data used, answers and users; set retention 30
Permission and misuse test cases, added to the test set 30
Monitoring and alerts for failures and unusual access 20
Stop switch, runbook and named owner 10
Security review support 20
Total 170

That's about 24% on top of the build. At $60–$90 an hour, governance adds roughly $10,000–$15,000. Ongoing, allow a few hours a month to review access and sample logs.

Now suppose the business wants the assistant to change delivery dates in the ERP. Add a write service that applies the ERP's rules, approval steps, limits, a way to reverse changes, and much heavier testing. Governance effort could easily double or triple, which is why starting read-only is the cheapest governance decision you can make.

What the Rules Require

Requirements depend on where you operate and what the system does, so take legal advice on your specific case. Two reference points:

  • The EU AI Act sets obligations for high-risk systems, including automatic logging of events and human oversight, with the ability to override or stop the system.
  • The NIST framework is voluntary guidance, widely used to organise controls.

Many business assistants won't be classed as high-risk. The same controls are still sensible, because they address real risks: data exposure, wrong actions, and not being able to explain what happened. The OWASP guidance on excessive agency is a practical guide to limiting what agents can do.

Who Should Own Governance

Controls fail when nobody owns them. Three roles are usually enough for a single system, and they don't need new hires:

  • Business owner: accountable for what the AI does in their process, and for the decision to widen what it's allowed to do
  • Technical owner: keeps logging, access and monitoring working, and handles incidents
  • Risk or compliance reviewer: checks the controls at launch and at each major change

In a small organisation, one person may hold two of these roles. The important thing is that the names are written down before launch. Time for these roles belongs in the budget, because it's often the largest ongoing cost.

Common Budgeting Mistakes

  • Budgeting for tools, not work. Software is the small part. Most cost is mapping permissions, testing and reviewing.
  • Treating governance as a final step. Retrofitting logging and access rules after launch means rebuilding parts of the system.
  • Applying one level of control to everything. Heavy review on low-risk reads wastes money and trains reviewers to click through without reading.
  • Ignoring the legacy audit. A shared account discovered in week eight changes the design and the estimate.
  • Forgetting retention. Logs containing personal data need retention limits as well as storage.

How to Keep the Cost Down

  1. Remove capabilities first. A permission that doesn't exist needs no approval step.
  2. Start read-only. Add writes only when the value is proven.
  3. Reuse existing platforms. Single sign-on, central logging and ticketing systems can often carry approvals and audit trails.
  4. Match controls to risk. Heavy review belongs on high-impact actions, not on every query.
  5. Design it in from the start. Adding logging and permissions after launch costs far more than building them in.
  6. Keep humans useful. Approval steps only work if reviewers can really review. See human-in-the-loop approval gates.

Ongoing Costs to Budget For

Governance isn't a one-off cost:

  • Access reviews as people change roles
  • Log storage, sized to your retention rules
  • Regular testing when models, prompts or systems change. Our AI agent evaluation framework covers this.
  • Incident handling: what happens when the AI does something wrong
  • Owner time: someone must read the reports and act on them

A common failure is a system launched with good controls and no budget to keep them running. A year later, the logs are unread and the access list is out of date.

Questions to Ask Before You Budget

  • What exactly can the AI see, and what can it change?
  • Can every action be tied to a person?
  • What's the worst realistic outcome if it's wrong, and how would we undo it?
  • What can our existing identity and logging platforms already do?
  • Who owns this system, and how much of their time is budgeted?
  • Which regulations apply to this data and this decision?

The answers tell you which controls you need, which gives you a far better estimate than any published figure.

Conclusion

AI governance for legacy systems doesn't have a standard price, because it depends on what the AI can do and what the old system lacks. As a planning guide, expect around 15–25% on top of a read-only build and considerably more for write actions. Audit the legacy system first, limit the AI's capabilities, reuse the platforms you have, and budget for keeping the controls running.

Schedule a strategy call with Cogniq AI to scope the controls for your integration, or explore our AI integration services.

Frequently Asked Questions

It depends mainly on what the AI is allowed to do. As a planning guide, the controls for a read-only assistant over one legacy system often add about 15 to 25 percent to the integration build, while an agent that writes to several systems can add 30 to 50 percent, plus ongoing review time. These are our planning ranges, not market benchmarks. Published budgets vary too widely to rely on, so estimate from the controls you actually need.

They measure different things. Some count only software tools, some include staff, and some cover a whole company programme rather than one system. A figure for an enterprise-wide programme says little about the cost of governing one assistant, so compare scope before comparing numbers.

At minimum: identity and access rules so the AI only sees what the user may see, logging of inputs, outputs and actions, a way to stop the system, testing before each release, and a named owner. Systems that take actions also need approval steps, limits on what can be changed, and a way to reverse changes. Legacy systems often need extra work because they lack modern permissions and audit trails.

They often use shared accounts, so activity cannot be tied to a person. Their permissions may be coarse or live inside the application rather than the data. Audit logs may be missing or incomplete, and business rules may be undocumented. An AI layer has to recreate or work around those gaps, which is where much of the governance effort goes.

It depends on where you operate and what the system does. The EU AI Act sets requirements for high-risk systems, including automatic logging and human oversight, while frameworks such as the NIST AI Risk Management Framework are voluntary guidance. Many business assistants are not high-risk, but the same practices reduce real risk. Take legal advice on your specific system.

Limit what the AI can do before adding controls around it. Start read-only, remove capabilities you do not need, reuse existing identity and logging platforms, and apply heavier controls only to high-risk actions. A permission that does not exist needs no approval step.