The AI Compute Constraint and the Case for an Intelligence Layer

The AI Compute Constraint and the Case for an Intelligence Layer

Article

The AI Compute Constraint and the Case for an Intelligence Layer

By AunalyticsMay 14, 2026

On May 6, Anthropic announced a new compute partnership with SpaceX. Buried in the announcement was a number that should reframe how every CIO in a regulated industry plans their 2026 AI roadmap: Anthropic is projecting roughly 80x demand growth in Q1 2026.

If that number holds, the race has shifted to compute, infrastructure, and orchestration capacity. The winners will be the enterprises that build an Intelligence Layer: the discipline and architecture to know when not to use frontier models.

For the last couple of years, enterprise AI strategy has had a simple shape: pick a frontier model, point your workflows at it, and let intelligence flow. That worked when usage was experimental, costs were absorbed in innovation budgets, and compliance teams hadn’t yet asked the hard questions. It doesn’t work at the scale we’re now entering.

Three forces are converging on enterprise AI:

Frontier capacity is constrained, and the constraint is physical.

Anthropic's deals with SpaceX, Amazon, Google, Microsoft, and NVIDIA are a signal. The frontier labs themselves are telling us the binding constraint has moved from capability to capacity.

Frontier models are economically inappropriate for most enterprise tasks.

A regulated bank doesn't need a trillion-parameter reasoning model to classify a transaction or route a service ticket. Sending those tasks to a frontier endpoint is the equivalent of dispatching a corporate jet to pick up the mail. It works. But it also burns capital that should be funding actual differentiation.

Regulated industries can't tolerate opaque dependencies on a single model path.

When every workflow is wired directly to a frontier API, you inherit that vendor's outages, rate limits, data residency posture, and pricing changes, with no control plane to absorb the shock. For a CIO at a regulated institution, that arrangement belongs on a risk register, not an architecture diagram.

The architectural conclusion: an Intelligence Layer

The strategic message is clear: frontier intelligence is becoming too expensive and too scarce to sit in the direct execution path for every request. Enterprises that recognize this are moving toward an architecture where frontier models are a selectively-invoked resource rather than the default destination for every request.

We call this an Intelligence Layer, and it sits between your business systems and the model landscape. It does five things:

  1. Routes each request to the right tier of intelligence (frontier, specialized, classical ML, or a deterministic rule);
  2. Governs policy, data residency, masking, and audit at the routing point before any data leaves your environment;
  3. Contextualizes the right enterprise data into the right prompt without leaking the rest of the warehouse;
  4. Orchestrates multi-step agent workflows so a single business task doesn’t become a hundred opaque API calls; and
  5. Observes every decision, model call, cost, and latency, turning AI from a black-box expense into a measurable operational system.

Framed plainly, the Intelligence Layer is the economic control plane for enterprise AI. It’s what allows a CIO to answer the questions a board is starting to ask: What did AI cost us this quarter? Which workloads drove the cost? Which of those workloads needed a frontier model? Are we compliant? Are we resilient if our top vendor has an outage tomorrow?

The opportunity hiding inside the constraint

Here’s the part that gets missed in the headlines about GPU shortages and gigawatt deals: scarcity is clarifying. It forces enterprises to ask a question they should have been asking all along, “What is the right intelligence for this task?” instead of defaulting to the most intelligence for every task.

Banks that get this right will see lower AI run-rates, faster compliance reviews, and better outcomes from the workflows that genuinely need frontier reasoning, because those calls will no longer be competing with thousands of trivial requests for the same capacity.

IT leaders who get this right will have something they can defend in front of a board, a regulator, and an auditor: a documented, observable, governed system for deploying AI — not a collection of integrations stitched into production.

The compute race that Anthropic’s announcement signals is real, and it will reshape the economics of this industry. But for the CIO of a regulated enterprise, the strategic question is less about how much frontier capacity you can secure and more about how much of your business genuinely needs it, along with how disciplined you are about routing the rest.

That discipline is the moat, and the Intelligence Layer is how you build it.


Aunalytics

Aunalytics is a data and AI company helping financial institutions use their data to drive deposit growth and engagement. By transforming their data into intelligence, we help teams grow deposits, enhance member relationships, and increase efficiency. Aunalytics provides software, infrastructure, and data strategy advice, guiding every step of your journey.


Memory-Centric AI: Your Real Advantage Isn't the Model

Memory-Centric AI: Your Real Advantage Isn't the Model

Article

Memory-Centric AI: Your Real Advantage Isn't the Model

By AunalyticsMay 11, 2026

In April 2026, Andrej Karpathy published a short essay on Wikis for LLMs. His argument: the enterprises that win with AI will be the ones that build, govern, and refine the curated knowledge their AI systems draw on, not the ones with access to the best models.

For a CIO in a regulated industry, that argument lands differently than it does for a startup. The shift from model-centric to memory-centric AI is the most important reframing of enterprise AI in the past year, with direct implications for how you spend your 2026 AI budget.

The Shift from Model-Centric to Memory-Centric AI

For three years, enterprise AI strategy has been organized around models. Pick the best one, prompt it carefully, and upgrade when something better ships. Performance, in most board decks, is a function of model capability.

That framing is starting to break.

CIOs running these systems in production are finding that two enterprises using the same frontier model can produce wildly different AI outcomes. The variable is what the model has been told about the business: the policies, definitions, prior decisions, escalation paths, and institutional rules that turn a generic LLM into something that behaves like a useful colleague.

Karpathy gave that body of knowledge a name: a wiki for the LLM. We’ve been building it under a different name — resolutions — inside our IT operations agent for months. The terminology matters less than the architectural conclusion both arrive at: the durable AI advantage is the curated memory the system draws on, not the model it calls.

What This Looks Like in Practice

Consider a recurring problem in IT operations: a Windows build update fails on an end-user device. A model-centric approach treats every occurrence as a fresh prompt and the work product evaporates the moment the ticket closes. A memory-centric approach captures the resolution as a structured, durable artifact that records the context, troubleshooting steps, and escalation criteria. Every subsequent occurrence draws on it, so the model applies a vetted answer instead of re-deriving one.

The economic difference is significant. Inference costs drop because known problems stop consuming frontier compute, and resolution times drop because the system is executing rather than reasoning. For a regulated environment, the bigger payoff is auditability: you can point a regulator at the exact knowledge artifact that produced an outcome.

The Failure Mode No One Warns You About

There is a specific risk in memory-centric AI that we’ve watched play out in real systems, and it deserves a CIO’s attention before it shows up in your environment. We call it error baking.

When AI systems enrich tickets, documents, or workflows by drawing on prior outputs, any error embedded in those prior outputs gets reused, reinforced, and amplified. A resolution that was 80% correct becomes the source material for the next resolution, which is now 75% correct, which trains the next one, and so on. There is no single moment of failure, just a subtle compounding drift.

The fix is governance at the memory layer, not better models: a reviewed, version-controlled knowledge base the AI is allowed to draw on, kept separate from the raw outputs it generates. Without that separation, your AI gets worse over time, in ways that are nearly impossible to detect from outside the system. With it, the system improves with every resolved incident, because every resolved incident becomes a vetted asset the next one builds on.

For a CIO in a regulated industry, this is the difference between an AI investment that compounds and an AI investment that decays.

Owning The Memory Layer

The memory layer is not documentation, and it is not a side project. It is infrastructure. It belongs in the same conversation as your data warehouse, access controls, and audit logs — because functionally, it is all three.

Three questions a CIO should be asking now: Where does our AI’s institutional knowledge live today — in prompts, in chat histories, in individual employees’ heads, in scattered Confluence pages? Who owns the curation, review, and version control of that knowledge? Can we point an auditor at the specific artifact that produced a given AI output?

In financial services, healthcare, and government IT, the answer to that last question is going to determine which AI workloads are allowed in production at all.

The Reframe

The competitive advantage in enterprise AI will not belong to the organizations that access the most capable models. Those models are becoming a commodity, available to your competitors on the same terms they’re available to you.

The advantage will belong to the organizations that own — and govern — what their models know.
That asset compounds, a regulator can inspect it, and a competitor cannot replicate it by signing a different vendor contract.

The model is rented. The memory is yours.


Aunalytics

Aunalytics is a data and AI company helping financial institutions use their data to drive deposit growth and engagement. By transforming their data into intelligence, we help teams grow deposits, enhance member relationships, and increase efficiency. Aunalytics provides software, infrastructure, and data strategy advice, guiding every step of your journey.


Use AI to Determine, Not Just Infer: Why Declarative AI Matters

Use AI to Determine, Not Just Infer: Why Declarative AI Matters

Article

Use AI to Determine, Not Just Infer: Why Declarative AI Matters for Regulated Institutions

AI companies are racing to convince you that their models are smart enough to figure out your business. However, most enterprise AI deployments quietly fail in the gap between that promise and what regulated institutions actually need — a gap that declarative AI is built to close.
By AunalyticsApril 24, 2026

You’ve probably sat through a compelling AI demo. Their model answers fluently, summarizes documents, and generates reports that look like what your team spends hours producing by hand.

But then someone in the room asks whether it knows how you define a primary banking relationship. They ask whether it applies your credit policy thresholds the same way every time, and what you’d show a regulator who questioned a decision it made. Those are the questions that separate AI that looks good from AI that works for your institution, in your regulatory environment, at the stakes you’re operating under.

The Flaw in Model-Centric AI

A growing number of AI vendors are building what are called model-centric systems, on the premise that a sufficiently capable model given enough of your data will figure out your business. The models are genuinely impressive, but model intelligence isn’t what solves the problem these institutions face.

Every regulated institution — community bank, credit union, company running enterprise IT under compliance requirements — operates on institutional knowledge that is declared rather than discovered. Your definition of a criticized asset, your risk rating thresholds, and your rules for what triggers a relationship review aren’t patterns hidden in your data waiting for a model to find them. They are decisions your institution has made, codified in policy, and required to be applied consistently across every loan review, compliance filing, and customer interaction.

When a model-centric AI system tries to apply your institutional logic, it doesn’t read your policy manual and execute it. It infers what your logic probably is, based on patterns in your data and whatever context you’ve fed it at the moment of the query. Every answer is a probabilistic approximation of a declarative truth.

That level of approximation is acceptable for marketing copy, but not for a credit decision, a regulatory disclosure, or a risk report going to your board.

Declarative AI vs. Inferential: The Distinction That Changes Everything

There are two fundamentally different ways to make an AI system work:

Inferential AI asks the model to reason its way to the right answer using whatever data and context you provide, making the model itself the intelligence layer. In theory, a better model produces better output. In practice, the model’s output varies based on how a question is phrased, what context was retrieved, and what version of the model is running, so there is no single authoritative answer, only the current best inference.

Declarative AI encodes your institutional logic into the data foundation before the model ever sees it, expressing your definitions, rules, and thresholds as an explicit, governed data architecture. The model doesn’t need to infer what “aggregate calendar-year deposits” means, because your intelligence layer has already defined and computed it. The job of the model is to reason over a foundation of established fact rather than construct that foundation on the fly.

For companies in regulated industries, it’s the difference between an AI system you can stand behind and one you can only hope doesn’t embarrass you in front of an examiner.

Why "Better Models" Aren’t the Solution

The standard vendor response is that models are getting better fast, and soon they’ll handle institutional complexity reliably. Models are improving rapidly, but improvement doesn’t resolve the declarative vs. inferential problem. A more capable model makes better guesses; it doesn’t turn guesses into facts. Your credit policy isn’t a pattern to be discovered at higher confidence levels. It’s a decision to be applied with complete consistency.

Governance is the dimension that will eventually land on a CEO or CIO’s desk personally. SR 11-7 and similar guidance require your AI systems to be explainable and auditable, which means when an examiner asks why a decision was made, “the model reasoned its way to this answer” isn’t a defense — it’s an admission. A governed rule with documented provenance is something you can put in front of a regulator, a board risk committee, or your own general counsel. Model weights are not.

There’s also a cost structure dimension that matters more the longer you run the system. Model-centric AI is a variable cost that scales with usage: every query, every user, every new workflow adds to the bill, and the more your institution embraces AI, the faster the number grows. Platform-centric AI is closer to a fixed cost you build once, where the marginal cost of additional use is near zero. Per-token prices will keep falling, but they won’t close this gap, because the volume of tokens required to re-derive your institutional context at query time doesn’t compress. By year three, the two architectures produce very different numbers on your P&L.

The Integration Problem Nobody Talks About

There’s a harder truth underneath all of this that the AI demos never address: most enterprise AI deployments fail not because the model isn’t good enough, but because the data isn’t ready.

Your customer records live in one system, transaction history lives in another, and loan origination data lives in a third. None of those systems were designed to talk to each other, and none of them have consistent definitions of shared concepts. “Customer” means something different in your core banking platform, your CRM, and your treasury management system.

Getting an AI model to reason accurately over that environment isn’t a prompt engineering challenge; it’s a data engineering one. It is the part most AI programs systematically underestimate. Resolving customer identity across a core banking platform, a CRM, and a treasury system, reconciling how Fiserv or Jack Henry structures accounts against your own definitions, and maintaining those definitions through core upgrades and acquisitions requires years of domain-specific work. When an AI initiative stalls or comes in over budget, this is almost always where it happened.

This is the work most AI vendors skip. They show you what the model can do once someone else has solved the data problem. They leave the data problem to you.

The data foundation is the moat — not because it’s expensive to build, but because it takes years to do right and it’s specific to your institution. When a competitor promises to replicate it with a smarter model, they’re proposing to shortcut a decade of domain-specific engineering. That’s not a technical claim. It’s a sales claim.

Three Things to Require Before You Commit Budget

If you’re a CEO or CIO evaluating AI investments, there are three things worth requiring of any vendor before you commit budget.

Require that your institutional logic lives in the data layer, not in the model or the prompt. Your definitions and business rules should be explicit, governed, and independent of the model, so they survive vendor changes, model upgrades, and staff turnover. If a vendor can’t show you where that logic lives, you’re being asked to store your institution’s intelligence inside someone else’s product.

Require a clear model-upgrade path that doesn’t put your institutional knowledge at risk. In a model-centric architecture, a model upgrade can invalidate the logic encoded in the current model, forcing you to revalidate your AI every time the vendor ships a release. In a platform-centric one, the intelligence layer is model-independent and the model is a swappable component. Ask your vendor to explain their upgrade path.

Require that every AI-supported decision be defensible to a regulator on its own terms. You should be able to point to the rule itself — when it was authored, what data it depends on, what it produces — not a description of what the AI probably did. If a vendor can’t produce that, you’re the one who will be asked to explain it.

Before deploying any AI agent or generative capability into a regulated workflow, verify that the underlying data is trustworthy, governed, and AI-ready, with resolved customer identity, codified business definitions, and derived intelligence maintained as standing metrics rather than computed on demand. Build incrementally, but anchor the roadmap on what architecture serves your institution in year three, not what you can show in thirty days. And insist on model independence, so that as foundation models improve, you benefit from the improvement without having to revalidate your institutional logic.

The AI companies competing for your budget are offering real capability, and the models are improving, but model capability is increasingly a commodity. What isn’t a commodity is a declarative AI foundation — governed, institution-specific, and built to give every model you deploy established fact to reason from. That foundation is what separates AI that works in a boardroom presentation from AI that works at 8 AM on a Monday, when your banker needs to know who to call, why it matters, and what to say — and needs to be sure it’s right.


Aunalytics

Aunalytics is a data and AI company helping financial institutions use their data to drive deposit growth and engagement. By transforming their data into intelligence, we help teams grow deposits, enhance member relationships, and increase efficiency. Aunalytics provides software, infrastructure, and data strategy advice, guiding every step of your journey.


AI is Only As Good As Your Data

AI is Only As Good As Your Data

Article

AI is Only As Good As Your Data

By AunalyticsApril 17, 2026

Every week, another AI vendor promises their platform will transform your financial institution. Better member insights, smarter lending decisions, and automated reporting. The pitch is compelling and the pressure to act is real.

Before you sign a contract, there’s a question worth asking: Do you actually have the data to back it up?

AI is only as good as the data underneath it. And most financial institutions don’t have the data that’s ready for AI yet.

The key is starting with your data foundation first.

For financial institutions, the challenge isn’t the amount of data, it’s the data readiness. When you skip the step of cleaning and structuring your data and go straight to the AI layer, here’s what happens:

  • The AI produces answers that feel authoritative but are statistically probable, rather than being declaratively accurate.
  • You can’t audit the decision: you don’t know why it said what it said.
  • You keep running the same calculations over and over, driving up costs with every query.

This isn’t a tech failure. It’s a sequencing failure. The intelligence has to be built into the data before you hand it to an AI.

What "AI-Ready Data" Actually Means

AI-ready data has been transformed, enriched with business logic, and structured so that when a question is asked, the answer is calculated, not guessed.

Think of it this way: if you ask an AI to tell you which members are at risk of leaving this quarter, it needs more than raw transaction records. It needs a unified view of each member’s relationship with your institution, behavioral signals over time, and the business rules your team uses to define “at risk” in the first place. That context must be built in.

The intelligence is in the platform. You must build it into the data layer before AI can deliver answers you can trust and act on.

Two Approaches and Why They're Not Equal

Approach One: Ask the AI to Figure It Out

Some vendors take raw data, often pulled from a cloud warehouse, and let the AI model do the calculations on the fly. The model ingests your data, runs its analysis, and returns an answer.

This sounds efficient. It’s not. Every calculation runs repeatedly, consuming tokens and compute resources with each query. Costs scale with usage, not with value. And when you ask, “why did you flag this member?” the answer is a statistical distribution, not a reason.

Approach Two: Pre-Compute the Intelligence

The more effective approach, and the one Aunalytics is grounded in, is to do the hard work before the AI ever sees the question. Every relevant metric, every business rule, every behavioral signal is calculated, validated, and stored in a structured intelligence layer.

When a question comes in, the AI retrieves a precise answer from data that was already prepared for it. The result is faster, cheaper, more accurate, and fully auditable.

This is what we mean when we say Aunalytics makes data AI-ready.

What This Means for Your Institution

If you’re a CEO, CIO, or CTO at a financial institution, this distinction matters for three reasons:

  • Accuracy: Declarative answers built on prepared data are more reliable than probabilistic outputs from raw data. When a banker acts on an insight, they need to trust it.
  • Auditability: Regulators and examiners want to know why a decision was made. With pre-computed intelligence, you can show your work. With probabilistic AI, you can’t.
  • Cost: Paying for compute on every query — at scale — adds up fast. Pre-computed data means you’re paying for results, not repeated calculations.

The Partner Question

Most community financial institutions don’t have the data science teams, the infrastructure, or the time to build this foundation themselves. They don’t need to.

But they do need a partner who’s already done the work — one who understands community banking deeply and can deliver production-ready AI data as a service.

That’s not a software tool. It’s not a dashboard. It’s a managed service built on years of experience working with the specific data structures, core systems, and regulatory environment of community banks and credit unions.

Aunalytics has been building and refining banking-specific data sets for over eight years. The Intelligent Data Warehouse isn’t a general-purpose platform adapted for banking. It was built for banking from the ground up.

Before you evaluate the next AI platform, ask the vendor one question:
What does your solution do to prepare my data for AI before the AI ever touches it?
The answer will tell you everything.

Start With the Right Foundation

The institutions that will win with AI aren’t the ones who adopt it fastest. They’re the ones who build the right foundation first — and find a partner who can help them get there without building a data science department from scratch.


Aunalytics

Aunalytics is a data and AI company helping financial institutions use their data to drive deposit growth and engagement. By transforming their data into intelligence, we help teams grow deposits, enhance member relationships, and increase efficiency. Aunalytics provides software, infrastructure, and data strategy advice, guiding every step of your journey.


Privacy Preference Center