Two findings from the last eighteen months sit awkwardly beside each other. McKinsey’s global survey reports that 88% of organisations now use AI regularly in at least one function, yet only about 39% can attribute any enterprise-level EBIT impact to it, and roughly 6% qualify as high performers with more than 5% of EBIT attributable to AI (McKinsey & Company, 2025b). MIT’s Project NANDA reports that some 95% of enterprise generative-AI pilots produce no measurable P&L effect, and that only about 5% of custom enterprise tools reach production (Challapally et al., 2025).

The constraint is not that the model is less capable.  It is more often than not a workflow integration and organisational redesign issue. McKinsey’s March 2025 survey tested around 25 organisational attributes and found that the fundamental redesign of workflows had the strongest association with EBIT impact from generative AI  (McKinsey & Company, 2025a).

The  current literature  hints that enterprise AI value capture is constrained by integration and workflow rather than model capability, that data governance and consumption remain weak links, and that  technology infusion in banking and finance  faces a persistent embedding problem.

In my previous description of the issue of emdedding AI efficiently, I   argued that

a) micro apps are the drill-down layer between broad-brush dashboards and action , and set out the data-architecture and end-user-computing conditions under which they are safe to build (Roy, 2026a);

b) AI resides inside micro apps — aids rather than rules — and the need to respect  model-risk boundary (Roy, 2026b).

This article underscores and articulates the relevance of micro apps in the workflow and why, without them the whole AI initiative gets constrained in value addition.

What a nano app is, and what it is not

For the purposes of this paper, I define a nano app as a small deployable unit of decision support: an application that answers one question, smoothens a single process  , , against one bounded data contract, and produces a limited range of  artifacts — a scorecard, red flags, a ranked exception list, a draft note.

It should own little or no dedicated persistent infrastructure; persistence it does require — storage, identity, logging, retention — is supplied by shared enterprise services rather than stood up per app. And it is disposable by design: when the question changes or the decision is retired, the app is retired with it. With little sunk cost. It is reusable, can be reprogrammed or discarded. But since commitment is low, it creates agile organizations.

There is also an architectural precedent. Micro frontends took the microservices argument — decompose the monolith into independently deliverable pieces owned by separate teams, and be explicit about the dependencies between them — and applied it to the user interface (Jackson, 2019). Nano apps apply the same decomposition logic one axis further over: not to the codebase or the interface, but to the decision. The unit of independence is a question someone has to answer, and the explicit dependency is the data contract.

Layer	Scope	Typical build	Owner	Lifespan	Governance posture
Enterprise platform	Many domains, many roles	12–36 months	IT / vendor	5–10 years	Full SDLC, architecture board
Domain application	One domain, several workflows	6–18 months	IT + business product owner	3–7 years	SDLC, change control
Micro/nano app	One workflow, one team	2–8 weeks	A Domain Expert/ Domain Team	1–3 years	Expert Control
Uncontrolled spreadsheet	One instance of one decision	Minutes	Often nobody of record	Indefinite in practice	Frequently none — the problem

 

The bottom row is the honest comparison. Nano apps do not principally compete with platforms; they compete with the ad-hoc spreadsheet and the manual read-through. Many institutions do operate disciplined end-user-computing frameworks with inventories, ownership and change control, and the argument here is not against spreadsheets as such. It is against the uncontrolled tail — the workbook with no owner of record, no version history, no documented logic and no expiry, which almost every organisation holds in quantity. Formalising the nano-app layer does not add that risk to the enterprise; it brings an existing risk inside the perimeter where it can be seen.

Nano apps are not AI agents

The two terms are frequently conflated and describe different things. A nano app is a statement about the scope and lifecycle of an application: how narrow its purpose, how short its life, how light its infrastructure. An agent is a statement about execution architecture: a system that plans, calls tools and acts with some autonomy.

A nano app may contain no AI at all — a rules engine over a certified dataset is a perfectly good nano app. It may use conventional statistical models, a language model for extraction, or an agent to orchestrate several steps. The governance consequences differ sharply across those cases, which is why the tiering framework below keys on decision consequence and degree of automation rather than on whether the word “AI” appears anywhere in the build.

Where they sit in the enterprise data pool

The conventional data architecture runs upward from source systems to consumption. Many enterprises build the first four layers well and then thin out:

1. Source systems — core banking, ledgers, CRM, regulatory returns, contracts, correspondence.
2. Ingestion and storage — lake, lakehouse, landing zones.
3. Conformed and semantic layer — governed definitions, certified metrics, lineage.
4. Data products — domain-owned, contract-bound, discoverable, versioned; the mesh principles of decentralised ownership with federated computational governance (Dehghani, 2019, 2020).
5. Model and AI services — scoring engines, forecasting, extraction, classification, retrieval.
6. → The nano-app layer ← — where a specific person, facing a specific decision, composes items from layers 3–5 into an answer.
7. Decision and action — the approval, the rating, the escalation, the letter, the limit .Audit Trail

The structural point: nano apps are not simply a consumption layer bolted on top of the data estate. They function as the link between the estate and the organisation’s judgement, and they run in both directions.

Why enterprise data models are value-constrained without them

Six constraints bind, and they compound.

1. The unused-data problem is largely a consumption problem, not a collection problem. IDC’s work for Seagate found that only about 32% of data available to enterprises is actually put to work, with the remaining 68% unleveraged, and identified usability, access and siloing rather than volume as the leading barriers (Seagate Technology & IDC, 2020). Enterprises have spent a decade solving collection and storage; the binding constraint moved to the last few metres.
2. Aggregation obscures the exception, and much of the value sits in the exception. Enterprise data models are optimised for generality — one schema serving many consumers. Decisions are often local, conditional and about a single entity. A portfolio-level ratio is primarily a governance artifact; it is rarely sufficient as a decision artifact. The moment a user needs to know which obligor, which branch, which clause, the enterprise model must be re-cut, and re-cutting requires an application. Without a cheap way to build one, the exception often goes unexamined.
3. The request queue is frequently longer than the decision window. A decision that must be made this week cannot wait for a change request scheduled next quarter. This is a principal mechanism generating shadow IT, and now shadow AI: NANDA reports personal AI tool use for work in over 90% of surveyed firms even where formal initiatives had stalled (Challapally et al., 2025). Suppressing that behaviour without providing a sanctioned alternative tends to drive it further out of sight.
4. The business-case threshold excludes the long tail. A platform investment must clear a material hurdle rate. The result is that enterprises reliably fund the twenty decisions that are individually large and reliably starve the two thousand that are individually small and collectively larger. Nano apps invert the cost curve: when build cost falls to hours, the hurdle falls with it, and the long tail becomes addressable. This is potentially one of the larger untapped value pools in a mature data estate.
5. Generic tools carry no workflow context. The NANDA “GenAI divide” turns substantially on this: general-purpose chatbots achieve high adoption for undemanding tasks and stall where a workflow requires memory, house methodology and context. A nano app is a context container. It encodes the enterprise’s own definitions, thresholds, rulebook references and materiality conventions, so that capability arrives pre-fitted to the decision.
6. Without a return path, less is learned than could be. An enterprise data model that flows only outward can improve its inputs but has limited means of improving its judgement. This is one reason programmes plateau after the first analytics wins: the organisation gets faster at producing the same reports without getting better at the decisions those reports were meant to inform.

In financial supervision, a comparable pattern is documented. The BCBS 239 principles have driven substantial investment in risk data aggregation capability, and the Committee’s recent outreach still reports persistent challenges in governance, data lineage and practical embedding (Basel Committee on Banking Supervision, 2013, 2026). On the supervisory side, the Financial Stability Institute has asked directly whether suptech tools have become embedded in supervisory processes or remain in extended experimentation (Prenio, 2024). The shape of the problem is similar: capability at the centre, thinness at the point of use.

What “structural resonance” means here

Resonance is the condition in which the granularity, latency and vocabulary of the data estate match the granularity, latency and vocabulary of the decisions being made. Where they match, small inputs produce disproportionate audible effects. Where they do not — daily data against annual decisions, portfolio metrics against single-name judgements, generic model outputs against house methodology — much of the energy stays unused.

Three tuning conditions follow:

• Granularity match — the app consumes at the grain the decision is made at, not the grain the warehouse finds convenient.
• Latency match — the app refreshes on the decision’s clock, not the batch’s.
• Semantic match — the app uses the enterprise’s certified definitions, so that two nano apps answering adjacent questions cannot silently disagree about what a term means.

 

Break any one and the result is proliferation without resonance: many apps, much activity, little coherence.

Value-addition opportunities

Value lever	Mechanism	Observable indicator
Decision compression	Assembly, reconciliation and comparison move from human to code	Elapsed time from data availability to decision
Exception surfacing	Screening runs across the full population instead of a sample	Share of population reviewed; exceptions found per reviewer-hour
Judgement capture	Inputs, outputs, overrides and rationale logged at the point of decision	Coverage of decisions with machine-readable rationale
Methodology encoding	Policy or framework rendered as executable logic, with judgement made explicit where it remains	Dispersion of outcomes across reviewers on identical inputs
Unstructured-data activation	AI extracts and classifies from documents; the estate gains fields it never had	Proportion of document corpus rendered queryable
Cheap hypothesis testing	A question can be tested for the cost of an afternoon	Number of tested-and-discarded hypotheses per quarter
Capability transfer	The app carries the method, so the method survives staff turnover	Time to competence for new staff on a given decision
Optionality	Small bets, cheap to kill, no sunk-cost defence	Retirement rate of the nano-app estate

 

Three of these deserve elaboration.

Methodology encoding is not uniformly deterministic. Hard thresholds and mechanical rules translate cleanly into code. Principles-based requirements, proportionality assessments and expert judgement do not, and forcing them into deterministic form produces false precision — a particular hazard in supervision, where the standard itself is often deliberately outcome-based. It is more useful to encode a methodology in three distinguishable parts: deterministic rules, where policy prescribes a mechanical outcome; structured judgement, where the app supplies the frame, the evidence and the prompts but the human supplies the assessment; and model-assisted judgement, where a statistical or ML output informs but does not determine the conclusion. An app that labels which parts are which is far more defensible than one that presents a single composite score.

The associated metric matters more than speed. If two experienced people score the same case differently, the organisation has an undocumented methodology problem that platform investment alone will not surface. A nano app makes that dispersion visible within a week.

Judgement capture is among the most important levers, because it is one of the few that improves next year’s models rather than only this year’s decisions.

But captured judgement is not automatically ground truth. Overrides and rationales may encode individual bias, inconsistent practice across teams, or historical error — including supervisory error. Feeding that material back into calibration or training without controls risks amplifying exactly the patterns the organisation should be correcting, and creates a self-confirming loop in which the model learns to reproduce past practice rather than good practice. Before the return path is used as training or calibration data it needs: quality review of the captured rationale; outcome tagging where later evidence reveals whether the decision was sound; provenance and versioning, so that judgements made under a superseded methodology are identifiable; and explicit monitoring for drift toward self-confirmation. The return path is an asset, but a supervised one.

Synergies the organisation should maximise

Nano apps × data products. Nano apps should consume contracts, not tables. A domain-owned, versioned data product with a published schema and quality guarantee is what makes a nano app safe to build in a day; direct queries against raw sources are what make the estate ungovernable. Data mesh is a particularly strong enabling architecture for this, but it is not a logical prerequisite: a well-governed central warehouse, a disciplined API layer or a lakehouse with certified marts can serve the same purpose. What matters is the contract, not the topology (Dehghani, 2020).

 

Nano apps × AI services. A useful shorthand is let AI read, and let code rule — but it is a heuristic with real limits, not a rule. Some scoring and classification legitimately depends on statistical or ML models, and extraction performed by a model can materially determine the output of the deterministic step that follows it, which means extraction quality is itself in scope for validation. The more defensible principle: use probabilistic inference where the task is genuinely inferential; use deterministic logic where policy prescribes a deterministic outcome; and retain traceability and human control wherever the matter is one of judgement. What must be avoided is not the use of models but the undeclared substitution of a model for a rule, which leaves nobody able to say how the answer was reached. The deployment patterns and logging conventions that make this boundary auditable in practice are set out in Roy (2026b).

Nano apps × platform investment. A nano-app estate functions as a discovery mechanism: usage reveals which questions are asked repeatedly, by how many people, with what consequence. That is precisely the evidence a platform business case typically lacks. Establish a promotion ladder with explicit gates:

A proportional governance envelope for nano apps

The preceding sections argue why nano apps should exist. This section addresses the harder question: when does an app stop being a nano app, and where should governance intervene? In regulated environments that distinction carries the weight of the argument.

The largest published account of what happens without such an envelope comes from Microsoft’s own internal estate. Having crossed a million citizen-development assets across more than 18,000 environments, Microsoft’s platform team describes the consequences of routing everything into a single shared default environment: broad accessibility creating oversharing and unintended data access, an inability to apply fine-grained data policy or role-based access per app or team, and an accumulation of assets at a scale that made monitoring impractical and isolated one app’s failure from nobody (Microsoft, 2025, 2026). Its remedy — routing makers into isolated personal environments under managed-environment controls, with policy applied by environment rather than by app — is the same structural move proposed here, arrived at from the platform side rather than the supervisory one (Microsoft, n.d.). The lesson generalises: the sprawl problem is not solved by discouraging small apps, and it is not solved by tooling alone. It is solved by deciding, in advance, which category an app belongs to and applying the corresponding controls automatically.

 

What breaks the resonance

• Sprawl without registry. No inventory, no ownership, no expiry. Within eighteen months nobody can say which apps are load-bearing.
• Silent methodology forks. Two apps encoding the same policy differently, both in production, both trusted.
• Orphaned apps. The builder moves on and the logic becomes folklore.
• Undeclared model substitution. A model quietly determining an outcome that policy assigns to a rule, or to a human.
• Data leakage. Convenience beating classification, particularly where apps handle documents or personal data.
• Promotion failure. A nano app relied on by two hundred people that was never re-engineered for that load or that scrutiny.
• Feedback-loop contamination. Captured judgement recycled into calibration without quality review, entrenching past practice as future standard.

Conclusion

Enterprise AI initiatives are not generally failing for lack of intelligence. They struggle because the intelligence is not fully utilized. It is not released in decision making, undermining the potential of data. Micro apps can help .

 

 

References

Basel Committee on Banking Supervision. (2013). Principles for effective risk data aggregation and risk reporting (BCBS 239). Bank for International Settlements. https://www.bis.org/publ/bcbs239.htm

Basel Committee on Banking Supervision. (2026, January 6). Implementation of the Principles for effective risk data aggregation and risk reporting (BCBS 239 Principles) [Newsletter]. Bank for International Settlements. https://www.bis.org/publ/bcbs_nl36.htm

Board of Governors of the Federal Reserve System. (2011, April 4). Supervisory guidance on model risk management (SR 11-7). https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm

Board of Governors of the Federal Reserve System. (2015, December 18; rev. January 15, 2021). Federal Reserve supervisory assessment of capital planning and positions for firms subject to Category I standards (SR 15-18). https://www.federalreserve.gov/supervisionreg/srletters/sr1518.htm

Broeders, D., & Prenio, J. (2018). Innovative technology in financial supervision (suptech): The experience of early users (FSI Insights on Policy Implementation No. 9). Financial Stability Institute, Bank for International Settlements. https://www.bis.org/fsi/publ/insights9.htm

Challapally, A., Pease, C., Raskar, R., & Chari, P. (2025, July). The GenAI divide: State of AI in business 2025 (v0.1, preliminary findings). MIT Project NANDA, MIT Media Lab. Originally issued at https://nanda.media.mit.edu/ai_report_2025.pdf; copy available here

Dehghani, Z. (2019, May 20). How to move beyond a monolithic data lake to a distributed data mesh. martinfowler.com. https://martinfowler.com/articles/data-monolith-to-mesh.html

Dehghani, Z. (2020, December 3). Data mesh principles and logical architecture. martinfowler.com. https://martinfowler.com/articles/data-mesh-principles.html

di Castri, S., Hohl, S., Kulenkampff, A., & Prenio, J. (2019). The suptech generations (FSI Insights on Policy Implementation No. 19). Financial Stability Institute, Bank for International Settlements. https://www.bis.org/fsi/publ/insights19.pdf

Financial Stability Board. (2020, October 9). The use of supervisory and regulatory technology by authorities and regulated institutions: Market developments and financial stability implications. https://www.fsb.org/uploads/P091020.pdf

Gartner. (2020, October 19). Gartner keynote: The future of business is composable. https://www.gartner.com/smarterwithgartner/gartner-keynote-the-future-of-business-is-composable

Gartner. (2021, September 21). Gartner survey reveals half of business technologists produce technology capabilities for users beyond their own department [Press release]. https://www.gartner.com/en/newsroom/press-releases/2021-09-21-gartner-survey-reveals-half-of-business-technologists-produce-technology-capabilities-for-users-beyond-their-own-department

Gartner. (2022, March 13). Gartner survey finds rise in business technologists is driving funding for tech purchases outside of IT [Press release]. https://www.gartner.com/en/newsroom/press-releases/2022-03-13-gartner-survey-finds-rise-in-business-technologists-is-driving-funding-for-tech-purchases-outside-of-it

Jackson, C. (2019, June 19). Micro frontends. martinfowler.com. https://martinfowler.com/articles/micro-frontends.html

McKinsey & Company. (2025a, March 12). The state of AI: How organizations are rewiring to capture value. QuantumBlack, AI by McKinsey. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value

McKinsey & Company. (2025b, November 5). The state of AI: Global survey 2025. QuantumBlack, AI by McKinsey. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Microsoft. (n.d.). Develop a tenant environment strategy to adopt Power Platform at scale. Microsoft Learn. https://learn.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy

Microsoft. (2025, September 18). Personal developer environments: Secure, governed innovation in Power Platform. Microsoft Power Platform Blog. https://www.microsoft.com/en-us/power-platform/blog/2025/09/18/personal-developer-environments-secure-governed-innovation-in-power-platform/

Microsoft. (2026). Empowering and securing our citizen developers with the Microsoft Power Platform. Microsoft Inside Track. https://www.microsoft.com/insidetrack/blog/empowerment-with-good-governance-how-our-citizen-developers-get-the-most-out-of-the-microsoft-power-platform/

Prenio, J. (2024). Peering through the hype: Assessing suptech tools’ transition from experimentation to supervision (FSI Insights on Policy Implementation No. 58). Financial Stability Institute, Bank for International Settlements. https://www.bis.org/fsi/publ/insights58.pdf

The rise of “micro” apps: Non-developers are writing apps instead of buying them. (2026, January 16). TechCrunch. https://techcrunch.com/2026/01/16/the-rise-of-micro-apps-non-developers-are-writing-apps-instead-of-buying-them/

Roy, S. (2026a). Financial sector micro apps: From broad-brush dashboards to nuanced decisions. sunandoroy.org. [URL to be inserted]

Roy, S. (2026b). The AI factor in micro apps. sunandoroy.org. [URL to be inserted]

Seagate Technology & International Data Corporation. (2020, July 15). Rethink data: Put more of your data to work — from edge to cloud. https://www.seagate.com/news/news-archive/seagates-rethink-data-report-reveals-that-68-percent-of-data-available-to-businesses-goes-unleveraged-pr-master/