AI-smart, not AI-first

Many companies are rushing into “AI-first” mandates right now. We’ve seen this pattern before. A decade ago, it was “cloud-first,” and it led to the same outcome: Fast adoption, thin governance and a wave of security and cost problems that took years to unwind. By 2019, OMB had to formally pivot federal policy from cloud-first to cloud-smart, not to slow adoption down, but to make it sustainable.

The lesson isn’t “move slower.” It’s “don’t generate operational debt in the name of speed.” That’s the lens I want to apply to AI adoption today, not as criticism of any one company’s approach, but as a pattern I think every technology leader is watching play out in real time.

What AI first gets right

The urgency is real. Competitive pressure is real. Waiting for perfect governance before adopting AI is not a serious strategy; companies that sit out lose ground they won’t get back. AI-first, as an instinct, is correct.

AI enabled: the step before AI first

Before an organization can responsibly go AI-first, it has to be AI-enabled: employees have access to sanctioned tools, data is structured for AI consumption and basic guardrails are already in place. AI-first without that foundation isn’t acceleration; it’s improvisation. Most of the ungoverned adoption happening today isn’t a failure of AI-first as a strategy; it’s organizations attempting AI-first while still being, at best, AI-enabled. Getting the sequence right, enabled before first, is itself a form of AI-smart.

Where it breaks down

The failure mode isn’t adoption; it’s unstructured adoption, adoption without a foundation to build on, without a path to scale and without security and accountability built in from the start. AI-smart isn’t a slower version of AI-first. It rests on one foundation and four pillars: A defined context to build on, a path to scale what works, security controls that hold up under agentic risk, clear governance over who owns what, and business value that justifies the exposure and existing tools transformation. Take away the foundation and the pillars have nothing to stand on; take away any one pillar and the structure leans.

The foundation: Context

Being AI-enabled gets an organization to the starting line, tools in place, data structured, guardrails established. Context is what turns that general readiness into a decision for a specific solution: What this particular AI system is allowed to touch. It’s the business data, systems and permissions a given solution is scoped to, not an implicit boundary inherited from whatever access the underlying service account happens to have, but an explicit one someone has deliberately set.

Getting context right, concretely, means being able to answer:

• What data can this solution see, and where does that data live?
• What systems can it call, and what actions can it take once it’s there?
• Who is it acting on behalf of, and does its access match that person’s or team’s actual permissions?

Where to start: The gate

Before any of the four pillars matter, a solution has to clear one checkpoint that AI needs as a discipline. I’d propose: Technical and Business Significance, a lightweight but mandatory gate that any AI solution has to pass before it’s approved for the environment, answering what it technically does, what data and permissions it touches, and what business value justifies that exposure. The same gate may include vendor, risk, compliance, legal and security reviews.

Everything below is what happens once a solution clears that gate and is granted “Technical and Business Significant” status.

Pillar 1: Scaling

Once a solution is approved and its context is defined, the question shifts from “should this exist” to “how does this grow without every team re-solving the same problems.” Without a repeatable path, each new team either re-litigates governance from scratch or skips it entirely to move fast.

• Build a reference pattern, a reusable architecture, access model and approval template, for each class of approved AI solution, so scaling reuses vetted patterns instead of one-off exceptions.
• Track adoption centrally enough to know how many instances of a pattern exist and who owns each one.
• Scale efficiently, not just widely: Route tasks to the right-sized model instead of defaulting to the largest one, cache repeated queries to cut cost and latency, and monitor token usage, inference costs and compute footprint, including Kubernetes-based inference scaling for LLM workloads, as adoption grows rather than reacting only after costs spike.

Pillar 2: Security

This is the technical control layer, the mechanisms that keep an approved solution from becoming a liability once it’s live:

• Shadow AI, evolved. It used to be unsanctioned SaaS. Now it’s unsanctioned MCP servers and API connectors, employees wiring an LLM directly into Jira, internal databases or SharePoint, often without security ever reviewing what data flows through or what the model is now capable of doing. It’s gone further still: users with no development background are using tools like Cursor to build and launch full applications on their own, with the intent to “review it later.” These apps go live before anyone in security even knows they exist.
• A new risk category, not just a bigger one. Traditional API risk is largely about data exposure. Agentic and MCP tool use adds an action dimension; a model can read, write, delete or trigger workflows. That’s a meaningfully different threat model than a chatbot saying something it shouldn’t.
• Governance built for the wrong actor. Most API security programs are designed around human or deterministic service-to-service calls. They weren’t built for a non-deterministic agent deciding, in real time, which calls to make. Least privilege and scoping matter more here, not less.
• Non-human identity, still catching up. Every agent, MCP server and API integration is effectively a new non-human identity with its own credentials and permissions. NHI governance was already immature before AI accelerated the problem, and it now needs significantly more investment: proper lifecycle management, credential hygiene and ownership, not just provisioning and forgetting.

Each of these risks points to the same remedy: Visibility and enforcement at the point where AI actually touches systems, not after the fact. That’s what the practices below are built around.

Foundational practices (start now):

• Inventory every MCP server and AI connector in use today, sanctioned or not.
• Route AI and agent traffic through a governed MCP gateway, the same enforcement point used for auth, scoping and rate limiting, rather than ad hoc integrations.
• Apply least privilege scoping to every tool an agent can call, and treat every agent as a non-human identity requiring lifecycle management.
• Log and monitor agent actions, not just model outputs.
• Be deliberate about AI-SPM investment. The category is real, but the value proposition versus existing CSPM and CNAPP tooling is still maturing for a lot of buyers. Buy for a defined problem, not a trend.

Emerging practices (industry still maturing):

• Extend DLP to cover agents that inherit user permissions, since an agent acting on someone’s behalf can move data just as easily as the user it’s impersonating, often faster and at greater scale.
• Register every agent in the CMDB as an independent entity, with a defined scope, owner and permissions set, not folded silently into the identity of the user or service that deployed it.
• Design for agent-to-agent (A2A) security deliberately, including on-behalf-of (OBO) flows, so that when one agent calls another, permissions are scoped and traceable rather than inherited by default.

Pillar 3: Governance and compliance

Where security is about technical controls, governance is about accountability, who owns a solution, whether it’s still operating within the bounds it was approved for, and what regulatory or policy obligations it has to satisfy. This is the layer that’s easiest to skip because nothing breaks visibly when it’s missing, until an audit, an incident or a regulator asks who’s responsible.

• Ownership as a first-class question. Every approved AI solution needs a named owner accountable for its behavior, not an assumption that whoever built it is still watching it.
• Compliance obligations tracked per solution. Data residency, industry-specific regulation and internal policy requirements should be checked at approval and re-checked as a solution’s usage evolves, not assumed to hold indefinitely.
• Vendor sprawl. Multiple teams independently contracting different engines — Copilot, Gemini, Claude — for materially the same use case isn’t resilience; it’s redundant spend and redundant risk surface. Multi-engine strategies are legitimate when deliberate and matched to real capability differences; they’re a governance failure when they’re just an artifact of teams choosing in isolation.
• Infrastructure sprawl. The same pattern plays out at the cloud layer: AI workloads landing on different clouds (AWS, Azure, GCP) not from deliberate architecture, but because different teams defaulted to whatever platform they already knew. Multi-cloud is a legitimate strategy when it’s intentional; it’s a governance gap when it’s an accident of who built what, where.

Foundational practices (start now):

• Assign and document an accountable owner for every approved AI solution at the time it clears the gate.

Emerging practices (industry still maturing):

• Build periodic re-certification into the governance cycle, confirming a solution’s scope, owner and compliance posture are still accurate, not just correct at launch.

Pillar 4: Business value

Context, scaling, security and governance answer how AI gets adopted responsibly. This pillar answers why a given solution deserves that investment in the first place, why an existing solution requires AI transformation and to what level. A value that justified a solution at approval time can erode as usage patterns shift, as the systems it touches change or as the business problem it was built for evolves. Treating business value as a one-time answer at approval, rather than something revisited as a solution scales, is how organizations end up maintaining AI capabilities long after the case for them has quietly disappeared.

• Transform existing systems into AI-enabled ones based on business need and known value. Replace them with AI-native systems only when replacement delivers better ROI, and the replacement is still technical and business-significant and scalable, and clears the same context foundation and the security and governance pillars.
• Revisit the value case at the same cadence you revisit context, not just at initial approval.
• Retire or re-scope solutions whose usage no longer matches the business justification that got them approved.

The business case

This isn’t a compliance argument. It’s a speed argument. Organizations that build context, scaling, security and governance in from the start scale faster, because they aren’t spending next year unwinding this year’s shortcuts. Cloud-smart didn’t slow federal cloud adoption; it made it durable. The same will be true here.

The vision

This isn’t about fear or slowing anyone down. It’s about making sure the AI adoption happening right now is still standing, secure and without a mountain of technical debt. That’s what “smart” means.