Governance has moved closer to the work

By Elton Tucker  |  Blue Mantis

Bottom line: AI governance cannot remain a policy document people are expected to remember. It has to become an operating capability—embedded in the workflows, platforms, identity controls, data protections, and decision paths where AI is actually being used.

Most organizations are no longer debating whether AI will enter the business. That part is already happening. The more useful question is whether the organization understands where AI is entering, who is making those decisions, what data is being exposed, and whether the current governance model can keep up.

That is where the phrase “shift left” deserves a fresh look.

In technology and security, shift left has traditionally meant moving responsibility earlier in the lifecycle: test earlier, secure earlier, design for operations earlier, and build quality into the process before defects become expensive problems.

AI changes the shape of that conversation. Governance is not only moving earlier in a development lifecycle. It is moving closer to the consumer of technology—the employee summarizing a customer interaction, the department leader enabling an AI feature in a SaaS platform, the analyst experimenting with automation, and the business team trying to move faster than a centralized approval process.

Those users are not necessarily acting irresponsibly. Often, they are doing exactly what the business asked them to do: improve productivity, reduce friction, respond faster, and find better ways to work.

But the operating model has changed. The people closest to the work are now making technology and data-handling decisions that once passed through architecture, security, procurement, compliance, or IT operations. The decision has shifted left. The risk has shifted left. The governance obligation has shifted left with it.

You Can Delegate Execution. You Cannot Delegate Accountability.

That principle is not unique to AI. It is already visible in established governance and regulatory frameworks. For example:

• OSFI Guideline B-10 states that federally regulated financial institutions retain accountability for business activities, functions, and services outsourced to third parties. Source
• HIPAA continues to govern uses and disclosures of protected health information by covered entities; introducing an AI-enabled workflow does not, by itself, remove those obligations. Source
• PCI DSS remains the industry standard for protecting payment account data, regardless of whether a new interface, copilot, or automation sits in front of the underlying workflow. Source

The common theme is straightforward: organizations can change how work is executed, but accountability for data, access, third parties, and business outcomes does not disappear. AI exposes the gap between those two concepts faster than most prior technology shifts.

Governance Cannot Stay in the Policy Binder

Most organizations already have policies that point in the right direction. Sensitive data should stay within approved environments. Customer information may have residency or retention requirements. Regulated workflows may require auditability. Intellectual property needs protection. Third-party risk needs to be understood. Human review may be necessary before AI-generated content is used in important business processes.

The weakness is not usually the existence of policy. The weakness is the operating assumption behind it: a person will read the policy, understand the nuance, remember it at the point of work, and apply it correctly under pressure.

That is a lot to ask when AI capabilities are appearing inside browsers, productivity suites, CRM systems, service platforms, collaboration tools, development environments, and industry applications. Employees are not always making a clean “AI tool” decision. Sometimes they are simply clicking a new feature inside a platform they already use.

If governance works only when the user pauses, interprets policy, and makes the right judgment call, the organization has not operationalized governance. It has delegated risk interpretation to the edge of the enterprise.

This is why machine-actionable policy matters.

Machine-actionable policy means governance is expressed in ways systems can interpret, enforce, monitor, and report on not only in documents written for people to read. The goal is not to remove human judgment. It is to stop pretending human judgment alone can scale across every prompt, integration, workflow, vendor feature, and business unit.

In practical terms, that can include:

• Data classification that restricts where sensitive information can be used or moved.
• Identity and access controls that consider role, device posture, location, application risk, and data sensitivity.
• Approved AI environments for experimentation, with clear boundaries for production use.
• Visibility into which AI-enabled platforms are in use and where adoption is accelerating.
• Logging and audit trails that can reconstruct material actions and decisions.
• Risk scoring and escalation paths that focus scarce technical attention where it matters most.

The Risk Is Not Just the Model

A lot of AI governance conversations start with the model: Which model are we using? Is it public or private? Does it retain prompts? How accurate is it? Can it hallucinate? Was it trained on appropriate data?

Those questions matter. They are not the whole picture.

For many organizations, the greater exposure may sit in the surrounding ecosystem: the SaaS provider embedding the AI feature, the integration moving data between systems, the identity model granting access, the employee workflow bypassing review, the logging architecture that cannot reconstruct what happened, or the third-party platform whose controls do not align with the organization’s obligations.

In other words, AI risk is rarely just an AI problem. It is also a:

• Data governance problem	• Vendor and third-party risk problem
• Identity and access problem	• Logging and observability problem
• Training and enablement problem	• Infrastructure and resilience problem
• Compliance problem	• Business-process problem

That is why the response cannot live inside one team. Security may own key controls. IT may own platforms. Legal and compliance may define obligations. Business leaders may own workflows. HR or enablement teams may own employee education. Architecture may help connect the pieces. No single group can govern AI responsibly if the operating model assumes everyone else is downstream.

AI governance must become a shared operating capability.

Awareness Is a Control—but Not the Only One

Employee awareness becomes more important in AI-enabled environments. People need to understand what information is appropriate for AI tools, which platforms are approved, when AI-generated output requires review, where customer or regulated data can be used, and when to escalate before proceeding.

But awareness alone is not enough. If the approved path is unclear, slow, or painful, employees will find another path. Shadow IT has existed for decades. Shadow AI is simply faster, easier, and often harder to see.

If the secure workflow takes three weeks and the unmanaged workflow takes three minutes, the policy has already lost part of the argument.

Good governance does not just say “no.” It creates a better “yes.” That may mean approved AI platforms, safe experimentation environments, validated use cases, reusable integration patterns, clear data-handling rules, embedded controls at the point of use, and practical examples that make acceptable behavior obvious and repeatable.

Mid-Market Organizations Feel This Pressure Differently

The AI governance conversation can sound as though it was written for very large enterprises with deep benches of specialized teams. Most mid-market and emerging enterprise organizations do not have that luxury.

They may not have a dedicated AI compliance function, a mature data governance office, or a platform engineering team ready to absorb every new requirement. At the same time, they face many of the same customer expectations, cybersecurity pressures, regulatory questions, third-party risks, and operational realities as larger organizations.

In that environment, AI governance cannot become another disconnected initiative. It needs to connect to work already underway.

A practical way to do that is to make AI part of the existing modernization agenda:

• If identity is being modernized, include AI access patterns and service identities.
• If data classification is improving, include AI inputs, outputs, and retrieval sources.
• If SaaS risk is being reviewed, include embedded AI features and data-use terms.
• If endpoint, browser, cloud, logging, or access controls are changing, include AI visibility and enforcement requirements.
• If resilience or recovery is being improved, include the AI-enabled business processes now becoming operationally important.

Not because AI is magic. Because AI exposes the seams that were already there.

Infrastructure Still Matters

It is tempting to discuss AI as if it lives entirely in the application layer. That is too narrow. Infrastructure choices determine what can be governed, monitored, segmented, audited, retained, and recovered. Hybrid environments, cloud platforms, data stores, APIs, identity systems, logging pipelines, and backup strategies all shape the organization’s ability to manage AI responsibly.

The architecture questions are operational questions:

• Where is data processed and stored?
• What systems does the AI capability touch?
• What logs are created, who can access them, and how long are they retained?
• Which workloads require additional sovereignty, residency, or regulatory controls?
• How are integrations secured and monitored?
• What changes if a use case moves from experimentation to production?
• What happens if a vendor changes functionality, terms, or data-handling behavior?

These questions determine whether the organization can prove what happened, enforce what should happen, and recover when something goes wrong. They also connect AI governance to the broader resilience and modernization agenda.

A More Useful Model: 360 Degrees of Risk

One useful way to think about AI governance is not as a hierarchy, but as a mesh. A hierarchy assumes policy is written centrally and pushed outward. A mesh recognizes that risk signals arrive from multiple directions: identity, data, vendors, applications, infrastructure, employee behavior, regulatory obligations, business workflows, and customer commitments.

That view is consistent with the direction of modern AI risk frameworks. NIST’s AI Risk Management Framework and its Generative AI Profile organize risk work around governing, mapping, measuring, and managing AI across its lifecycle. ISO/IEC 42001 similarly treats AI governance as a management system that must be established, operated, evaluated, and continually improved.

NIST AI Risk Management Framework resources  •  NIST Generative AI Profile  •  ISO/IEC 42001 overview

A practical starting point is to ask ten questions:

1. What AI capabilities are already in use?
2. What data can those capabilities access?
3. Which use cases are approved, tolerated, unknown, or explicitly prohibited?
4. Which policies still depend entirely on human interpretation?
5. Which controls can be automated or embedded into workflows?
6. Which vendors introduce material AI-related risk?
7. Where do employees need clearer guidance or a faster approved path?
8. Where does infrastructure limit visibility, control, or auditability?
9. What would we need to prove if something went wrong?
10. What does “better” actually mean for the business?

That last question matters. Better cannot simply mean “more AI.” Better may mean faster service without exposing customer data. Better may mean improved productivity without losing auditability. Better may mean more automation without creating brittle operations. Better may mean safer experimentation without burying teams in process.

If the organization has not defined better, AI adoption will optimize for whatever is easiest to measure, easiest to buy, or easiest to demo. That is not governance. That is momentum.

The Leadership Work Is to Make Responsibility Scalable

AI governance is often framed as a control problem. It is also a leadership problem.

Leaders need to create the conditions where responsible adoption is possible: clear intent, visible ownership, practical guardrails, and a shared understanding of what the organization is trying to accomplish.

The useful leadership posture is not, “We have all the answers.” Most organizations do not. A stronger posture is: “Here is what we are trying to enable. Here is what we need to protect. Here is what we know. Here is what we are assuming. Here is where we need more visibility. Here is how we will learn without pretending the risk is not real.”

That transparency builds trust. It also gives technical teams room to do the work properly—not perfectly, properly.

What This Means in Practice

For organizations trying to move from policy to operational governance, the near-term objective is not perfection. It is repeatability. Start by making the responsible path easier to identify and easier to use.

Three principles and five actions that are common to successful adoption at scale.

Three principles for responsible AI scale

AI is an operating model shift.

It changes who can make technology decisions, where those decisions occur, and how quickly new capabilities reach employees and customers. 

AI scale depends on a rationalized foundation.

Identity, data, infrastructure, applications, cost controls and observability determine whether AI can move from pilot to production without creating unacceptable operational debt.

Governance is trust at scale.

The goal is not more approval gates. It’s creating enough visibility, ownership and enforceable boundaries that people can move faster without asking the organization to accept risks it cannot see.

Five steps for responsible AI scale

• Clarify ownership. What are we trying to accomplish? Decide who owns the business outcome, who defines acceptable risk and who has authority to approve movement from experimentation to production.
• Rationalize the foundation. Understand applications, data, infrastructure, dependencies, technical debt and where AI is already entering.
• Modernize your identity and access. AI dramatically expands the importance of identity governance management as we expand to include. Not just human identities, but also services, agents, applications, and machine to machine patterns.   Make access decisions based on users, workloads, data sensitivity and context rather than static perimeter assumptions.
• Operationalize policy, economics and controls. Translate policy into enforceable controls, establish cost visibility, and introduce financial and technical guardrails. AI can introduce new and sometimes difficult-to-predict consumption patterns across cloud infrastructure, data, compute and AI services. Cost governance should therefore be established early rather than addressed after adoption begins to scale.
  If you do not already have a robust FinOps capability, begin building one now. The same disciplines that create visibility and accountability for cloud consumption become increasingly important as AI workloads grow and evolve.
• Scale AI deliberately. Take what works and build on it.   Expand the use cases that demonstrate value while maintaining visibility, accountability and repeatability.

AI adoption will continue. The organizations that do best will not necessarily be the ones with the flashiest tools or the most ambitious pilots. They will be the ones that make responsible adoption repeatable—connecting policy to platforms, awareness to workflows, infrastructure to accountability, and innovation to business outcomes.

The objective is not to add another layer of process around AI. It is to connect these capabilities so that business leaders, technology teams and risk owners can make better decisions from a shared understanding of what the organization is trying to enable, what it needs to protect, and what must become true to move forward responsibly.

That is less glamorous than the AI mythology. It is also more likely to work.

Where we can help

The challenge is that none of these steps exist in isolation.

Identity decisions affect data access. Infrastructure choices affect visibility, resilience and economics. Security controls affect how quickly new use cases can move into production. Governance determines whether the organization can demonstrate that those decisions remain inside acceptable boundaries.

This is where Blue Mantis can help. Rather than treating AI readiness as a standalone technology initiative, we can work across the underlying disciplines that determine whether AI can move from experimentation to responsible scale:

• Modernization and infrastructure — rationalizing the platforms, workloads and dependencies AI will rely upon.
• Identity and access — establishing appropriate access patterns for users, applications, services and emerging AI agents.
• Data governance — understanding what data AI can access, where it can move and what obligations follow it.
• Cybersecurity and resilience — embedding visibility, protection, auditability and recovery into AI-enabled workflows.
• FinOps and cloud economics — making consumption, cost and business value visible as AI workloads scale.
• AI readiness and adoption — helping organizations identify viable use cases and establish a repeatable path from experimentation to production.

Sources and Further Reading

• AI & Data | Blue Mantis
• NIST, AI Risk Management Framework resources
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Office of the Superintendent of Financial Institutions (OSFI), Guideline B-10: Third-Party Risk Management
• U.S. Department of Health and Human Services, Summary of the HIPAA Privacy Rule
• PCI Security Standards Council, PCI DSS Document Library
• ISO, ISO/IEC 42001:2023 – Artificial intelligence management systems
• About the author:
• Elton Tucker is an Enterprise Architect with a background in digital transformation, enterprise architecture, strategy consulting, solution and cloud architecture, and IT outsourcing.   Over the past 30 years he has worked with multiple global 500 organizations across industries including Information Technology, Financial Services, Insurance, Telecommunications, Manufacturing, Health Care / Life Sciences, Energy, and Automotive.
  
  In his current role as pre-sales enterprise architect for Blue Mantis, Elton brings his extensive experience to help guide across multiple technical domains and disciplines.   His goal is to simplify, clarify, and communicate programs of change to drive business value.