Most AI (artificial intelligence) programs in regulated organizations do not fail. They stall. Seats are bought, a few pilots look promising, usage climbs for a quarter and then flattens. This chapter names the six patterns behind the stall, and tells one story that shows what a stall costs in production.
1. Six stall patterns
Each pattern looks like progress from the outside. The fix is never "more enthusiasm"; it is a missing step that a later chapter supplies.
| Pattern | What it looks like | Why it happens | The fix, and where |
|---|---|---|---|
| Tool without context | Everyone has a coding assistant; the output is generic and ignores the team's own libraries | The AI sees the open file, not the team's conventions, catalog or domain rules | A team instructions file and an asset catalog the agent queries (chapter 7, lab 1) |
| Pilots with no path to production | Five pilots demo well; none ships; a sixth starts | No intake, no risk tier, no evaluation set, so nobody can say "this is safe to run" | Use-case intake and risk tiers at the start (chapter 3, chapter 4) |
| Risk sign-off at the end | Privacy or model risk sees the use case the week before launch and stops it | Risk was treated as a final gate, not a design input | Governance first: tier at intake, controls designed in (chapter 2) |
| Measuring seats, not depth | The dashboard shows licences and weekly active users; value is a guess | Seats are easy to count; net time saved and rework are not | A balanced metric tree with denominators and owners (chapter 10) |
| Training without practice | A one-hour webinar per tool; a month later, behavior is unchanged | People learn a tool by using it on their own work, with someone to ask | Labs on real tasks, office hours and a coaching cycle (chapter 9, chapter 12) |
| Governance seen as the blocker | Teams route around review, or wait for it, and blame it either way | Controls exist on paper but not as paths: nobody knows what is approved for what | An approved-tool list, risk tiers and guardrails as code that make the safe path the fast path (chapter 5) |
The patterns feed each other. A tool without context produces duplicate code. Duplicate code produces rework. Rework makes risk nervous, and a nervous risk function signs off late.
2. The ten implementations
The organization in the running example is a regulated consumer-finance company. It needed every channel to show the contractual payment due date the same way. When the architect ran an impact analysis, the search found ten different date-and-time implementations across services (the count is illustrative).
| What was found | Count | What it did |
|---|---|---|
| Correct | 7 | Treated the due date as a calendar date and printed it as written in the contract |
| Wrong | 3 | Parsed the date-only value as an instant, at midnight UTC (Coordinated Universal Time), then converted it to the customer's time zone |
| Shared library | 1 | shared-datetime already existed, with date-only types, instant-plus-zone formatting and a business-calendar API |
The three wrong implementations made the same mistake in three different ways. Midnight UTC on 15 November is the evening of 14 November in America/Los_Angeles. So West-coast customers saw their due date one day early, on the surfaces those services fed.
Nobody wrote a bad function on purpose. Each team needed "format a date", wrote a small helper, and moved on. The shared library was not in a catalog anyone searched, and the coding assistant was never told it existed, so it generated a fresh helper each time in seconds.
3. The lesson: reuse is a control
DRY (don't repeat yourself) is usually sold as tidiness: less code, less maintenance. In a regulated domain, that undersells it. Reuse first is a domain-correctness control: the shared library encodes the rule that a due date is a date, not an instant, and every copy is a chance to lose that rule.
AI makes this sharper, not softer. A coding agent can write a plausible date helper faster than a developer can search for the library. Unless the agent is told to look first, adoption multiplies the duplicates.
| Without reuse first | With reuse first |
|---|---|
| Each team writes its own helper | The agent queries the asset catalog before writing a utility |
| The domain rule lives in ten places, three of them wrong | The rule lives in one temporal-domain contract, owned by architecture |
| Review catches the bug only if the reviewer knows the rule | A CI (continuous integration) check blocks the known bad pattern on date-only fields |
| The decision to build new is invisible | The developer records reuse, extend or create, with a reason |
A reuse hook nudges and blocks known patterns. It cannot prove that no duplicate exists. That is why the catalog, the decision record and the CI check work together, as chapter 7 describes and the worked example shows end to end.