I’m a finance professional at a large bank in Asia, where a significant part of my work has come to involve AI adoption — building internal tools and analytical infrastructure, and more recently working with a cross-functional team focused on helping different business teams identify how AI can improve their workflows. That means a lot of conversations: with managers, with risk stakeholders, with teams who are enthusiastic and teams who are sceptical. The framework I’m describing here came out of that work directly.
This post was written with the assistance of Claude. The ideas and direction are my own; the AI helped compile and draft the content.
The typical enterprise AI framework organises adoption by use case or deployment stage. This one takes a different cut.
Enterprise AI conversations tend to default to one of two registers: the breathless inventory of what the technology can do, or the cautious enumeration of what it shouldn’t. What gets discussed less is a more foundational question — how to think about where AI actually sits within an organisation, and what that placement implies for governance, adoption, and impact.
I’ve found it useful to organise AI use cases not by feature or tooling, but by a simpler criterion: who is the audience, and what consequence does the output carry? That lens produces a three-layer framework — less a roadmap, and more a diagnostic aid.
The Three Layers
Layer 1 — Personal Productivity AI assists an individual employee in their own work. Drafting emails, summarising documents, generating first-cut analyses, navigating internal knowledge bases. The output is consumed by the person who prompted it. The consequence is personal and contained.
Layer 2 — Process Enhancement AI is embedded into a shared workflow or operational process. A data dashboard assembled by AI rather than manual Excel wrangling. An automated reporting pipeline that a team lead monitors. The output serves a defined internal process, and its reliability has organisational dependencies — but the primary consumer remains internal, and the stakes are operational rather than decisional.
Layer 3 — Business Outcomes AI contributes directly to outputs that inform significant decisions or reach external audiences. An investment analysis reviewed by a senior executive before a capital deployment. A client-facing report or recommendation. The output either influences a high-stakes internal decision or leaves the organisation entirely.
| Layer | Primary audience | Typical consequence | Governance | Example use case |
|---|---|---|---|---|
| Layer 1 Personal productivity | The individual who prompted it | Personal and contained — no organisational dependency |
Low | Drafting emails, summarising documents, first-cut analysis |
| Layer 2 Process enhancement | Internal team or process owner | Operational — reliability has organisational dependencies |
Moderate | AI-generated internal data dashboard replacing manual reporting |
| Layer 3 Business outcomes | Senior decision-makers or external clients | Decisional or reputational — output informs high-stakes action or leaves the organisation |
High | Same dashboard surfaced to executives or clients to inform investment decisions |
Why the Technology Doesn’t Determine the Layer
What distinguishes these layers is not the underlying AI model, the tooling, or the sophistication of the workflow. It is the data that goes in and the way the output is used.
In cross-functional work across technology, business, and risk, two implementations can look nearly identical technically — same model, same interface, same data pipeline — and sit in entirely different governance categories because of who ultimately acts on the output and what they do with it.
Consider a data dashboard. Built to help a team manager track process metrics and eliminate weekly manual reconciliation, it is a Layer 2 implementation — genuinely valuable, clearly process-enhancing. Now take the same dashboard, feed it data that informs client portfolios, and route its output to a senior decision-maker or to clients directly. The AI underneath may be identical. The governance requirements are not.
This distinction resists a common conflation: assuming that if the AI component is the same, the risk and oversight requirements can be the same. Layer 3 implementations require a systematic review of input data quality, output interpretability, and downstream accountability that Layer 2 implementations may not. The question is not what is the AI doing — it is who acts on the result, and with what consequence.
Layer 1 Is More Important Than It Looks
Personal productivity use is often treated as the baseline — the less interesting layer before the real work begins. That framing undersells it.
Layer 1 is where organisational trust in AI tools gets built. In our experience, as models improve and integrations with enterprise systems deepen, individuals who find personal productivity use genuinely useful become more willing to engage, more willing to experiment, and more willing to advocate for workflow-level adoption. Layer 1 is not a waiting room. It is the on-ramp.
The manager dimension compounds this. In our observation, teams whose managers are active AI adopters tend to be stronger adopters overall. A manager who has personally experienced the tool’s value, and formed their own view of where it can and cannot be trusted, is far more likely to open up team workflows for optimisation. Scepticism at the management layer tends to suppress adoption well below what individual interest might otherwise sustain. Layer 1 adoption by people in leadership positions has disproportionate downstream effects — not because of formal authority, but because of the trust signal it sends.
The Transition Beyond Layer 1
For organisations with established systems and workflows, initial AI rollouts typically land at Layer 1 — and that is appropriate. Personal productivity improvements are low-risk, fast to deploy, and generate the kind of bottom-up enthusiasm that sustains broader adoption.
The transition to Layer 2 or 3 seldom happens organically. It requires someone — a manager, an AI champion, a cross-functional team — to ask: where in our existing workflows is AI creating friction by its absence? Layer 2 opportunities often surface quickly from that question. Teams reviewing their processes for AI leverage tend to find obvious candidates within the first sitting.
Layer 3 is different. It rarely emerges from a workflow review alone, because it requires an additional conversation about risk: not just can AI improve this process, but what are the implications if the output is wrong, and who is responsible? That conversation benefits from involving technology, business, and risk stakeholders together — and from being explicit about the audience and consequence at the outset. Which is precisely where the three-layer frame earns its keep.
Using the Framework
The three layers are not a maturity model. An organisation does not need to graduate from Layer 1 before pursuing Layer 2, and running significant Layer 1 usage alongside early Layer 3 pilots is entirely coherent. The value of the framework is diagnostic, not sequential.
In practice, I use it in two related ways. The first is as a conversation opener when approaching a new team. Asking a manager how they use AI tends to surface both their actual familiarity with the tools and their openness to going further. It’s a low-pressure way to calibrate where the team is without leading with a pitch.
The second is as an analytical tool during workflow reviews. When a team maps out their existing processes and we start identifying where AI could help, the layer classification helps differentiate readiness and risk. A Layer 2 candidate might be actionable in weeks with minimal governance overhead. A Layer 3 candidate might be the higher-value opportunity but require a more deliberate design process involving risk and compliance stakeholders. Knowing which is which early shapes the entire approach.
The right question, in most cases, is not what does the AI do — it is who uses the output, and what happens next.
If you’re working through similar questions in your own organisation — whether on the business, technology, or risk side — I’d be glad to compare notes.