Shadow IT as informal settlement: map it first

The file is called “adjusted prices FINAL reviewed” and it arrives by email whenever someone in sales needs to quote a price the official list doesn’t cover. In Digital-World Urbanization (DWU), that spreadsheet is an informal digital settlement, a locally useful solution created outside shared architecture, governance, ownership or lifecycle controls, and that’s how I propose treating shadow IT in general. First it goes on a map; then you decide what to do with each settlement.

The sheet belongs to Northstar Consumer Group, a fictional regional manufacturer and retailer with five legal entities in five countries, which I use as the running case in the digital urbanization series. Someone in the Commercial district (the business domain that owns sales and its metrics) put it together to get through a bad afternoon, someone else added a column, and now several copies with different values circulate between inboxes. It works well enough that quotes go out the same day. It also exposes customer-level negotiated prices to anyone who receives a forward.

Four settlements at Northstar

At Northstar the sheet is one of four settlements. A regional manager built a low-code app to record field visits. It runs on a platform the company licenses and uses corporate identity for sign-in, but it isn’t registered, no one is assigned to maintain it if the manager moves on, and it has no review date. A nightly script reconciles orders between e-commerce and the ERP using svc-integracion, a service account it shares with other integrations. And several analysts paste customer data into an AI assistant the company never contracted.

All four solve something the business needs. Quotes go out the same day, the app won adoption in its region without anyone imposing it, orders drift apart without the script, and the assistant helps each analyst with analysis and writing. Three of them also carry a high risk that nobody manages. The sheet puts customer prices in every forward and its copies no longer match, the script depends on an unmonitored shared account and on the person who wrote it, and the assistant sends company data out with no contract or audit.

Banning them is the fastest response. But banning a settlement without addressing the need that created it usually just displaces it. If Northstar blocks the assistant tomorrow, the need for analytical help is still there, and it resurfaces in another service that may be harder to see.

What a settlement is and what it signals

DWU treats all four with a single construct, the informal settlement, and with its tenth principle, visible informal growth. The definition joins four conditions with an “or”, so falling outside any one of the four controls is enough to make a solution informal. The field-visit app is informal on ownership and lifecycle, even though technically it lives on formal ground.

The term covers what the industry calls shadow IT (spreadsheets, local databases, scripts, low-code apps, duplicated dashboards) and also unsanctioned AI, which falls into the same category. The analyst who pastes customer data into the assistant is building a settlement with the same logic as whoever built the pricing sheet. What changes is how fast it can move data out of the territory, the legal and risk perimeter within which the company has authority to set rules.

I prefer “settlement” to “shadow IT”. “Shadow” suggests something hidden on purpose, and most of the settlements I’ve come across were never hidden; nobody had asked about them. The urban term describes a position relative to the formal city (the architecture, platforms and processes the company governs) and leaves out any judgment about the person who built it. That judgment, as I argued in useful organizational deviance, is almost always decided by the outcome: the same tool is called initiative if it worked and recklessness if it failed. That label says nothing about the tool’s risk.

DWU proposes that low habitability encourages informal settlements. Digital habitability is the degree to which the environment lets its inhabitants (people, systems and agents) work safely and effectively under rules they can understand. When the formal city doesn’t meet a need at an acceptable speed, someone builds their own. That’s why settlements are diagnostic signals as well as compliance failures, and they can point to unmet demand, inaccessible infrastructure or excessive regulatory friction.

All three show up at Northstar. The script exists because its author had no governed route within reach (an API, an event or a queue with a contract and monitoring) between e-commerce and the ERP. That’s inaccessible infrastructure, and the author made do with what was at hand, the shared account. The assistant reads better as regulatory friction. In my version of the case, approving an AI tool takes security, legal and data reviews that no analyst can get through before a deadline. The pricing sheet and the field-visit app signal unmet demand, capabilities the business needs and that Commercial hasn’t yet taken on.

The diagram separates two relationships that tend to get mixed up. The first is reciprocal, a tension the framework acknowledges. Low habitability can generate settlements, and widespread settlements can reduce habitability further. At Northstar, every copy of the sheet in circulation erodes the credibility of the ERP price, so the next salesperson trusts the sheet a little more, and the sheet becomes more necessary. The second relationship is proposition P5, in the box on the right, which links settlements to forms of urban debt and which I come back to below. The dashed path at the bottom is the one the rest of this post follows. The settlement is read as a signal, and the map sends that signal back to correct the formal city.

Map first

The method has four steps, in order: map the settlements, identify the capability they serve, assess their risk and value, and choose a response. Principle 10 states it as a rule. Informal growth gets mapped and brought under governance progressively, and prohibition is one possible response among several.

Traces and capabilities

The search starts with the traces settlements leave in public infrastructure, the shared identity, audit, observability and platform services. At Northstar, the sheet shows up in the mail logs as an attachment forwarded again and again. The field-visit app is listed in the low-code platform’s inventory with no registered owner. The script leaves nightly svc-integracion sessions from a server that doesn’t belong to any registered integration, and the assistant shows up in outbound traffic to external AI services. That finds the settlement, but the capability it serves only shows up when you talk to the people who use it.

Over the years I’ve learned to distrust the first inventory. It comes back short, because people declare what they think won’t be taken away. For someone to tell you what they built, declaring it has to cost them less than staying quiet.

Identifying the capability is the step people skip most often, and the one that changes the conversation. On the map, the sheet is recorded next to the capability it serves, approving and communicating customer-specific exception prices, which belongs to the Commercial district. Once it’s named that way, the question becomes where that capability should live in the formal city.

Northstar’s inventory

Four responses

DWU names four responses (recognition, integration, relocation and retirement) without defining them in detail or saying when to use each. What follows is my operational reading, and I tell them apart by what changes in each case.

When you recognize a settlement, only its status changes. It stays where it is and enters the registry of Northstar’s buildings, meaning its applications, products and services, with owner, purpose, users, dependencies, cost, lifecycle state and renewal decision. When you integrate it, it also stays put, but it gets connected to public infrastructure (identity, audit, observability) and to governed routes and data. When you relocate it, whatever it contains moves into a formal building, data, rules and users included, and the settlement is dismantled once the move is done. When you retire it, it’s switched off and nothing it contains is inherited. If the demand is still alive, meeting it is a separate decision.

A matrix for choosing

To choose, I use a value-versus-risk matrix. It’s my own heuristic, built in practice.

The vertical axis measures the value the settlement delivers that the formal city doesn’t offer today, because absolute value misleads. The pricing sheet is worth a great deal as long as there’s no other way to approve an exception price, and almost nothing the day there is one. The horizontal axis measures risk to the enterprise. To estimate it, I ask whether the settlement duplicates data, creates hidden dependencies, opens control gaps or generates rework, which are the consequences P5 associates with settlements.

In the high-value, high-risk quadrant I need a second question, about where the risk sits. For the script it sits in the connections (the shared account, the missing monitoring), and connecting it better fixes that. For the sheet the risk is in the medium itself. An email attachment can’t be connected to anything, so what moves is the capability.

The AI assistant lands in the same zone as the sheet today, but there’s nothing to move, because Northstar doesn’t control the tool and the analysts’ conversations stay in an external service. Once a sanctioned assistant exists with a civic identity (its own identity, a sponsor and scoped permissions, as I develop in the post on agent governance), the unsanctioned one no longer offers anything the formal city lacks, and the dot drops into the retirement quadrant. Retiring it before that alternative exists repeats the displacement I described with the ban.

The registry entry

Here’s what the script’s entry in the registry could look like. Owner, district and dependencies come from the building registry the framework proposes for Northstar; capability, value, risk and response come from the mapping practice. The format and the other fields are mine.

# Northstar settlement registry (fictional case, illustrative format)
id: nightly-order-reconciliation
type: scheduled script
capability: reconcile orders between e-commerce and ERP
district: undecided                # Commercial or Supply chain
owner: unassigned                  # a finding of the map
dependencies: [ERP, e-commerce]
current_identity: svc-integracion  # shared with other integrations
signal: no governed order route
value: high
risk: high
response: integration
conditions:
  - own identity with least privilege
  - logs and a failure alert in shared observability
  - owner named before the next review
planned_exit: consume the order-confirmed event instead of reading ERP tables

Most of the fields are bookkeeping. district: undecided shows that the map found a capability no district has taken on, a zoning problem (which district owns which capability) the script was covering up. planned_exit puts in writing that its current connection is temporary. Its direct reads of ERP tables are one of the improvised roads I described in the post on point-to-point integrations, and the day the governed route exists the script leaves those tables and consumes the event.

The Grupo Diveco case

The story behind Portal Diveco, the Grupo Diveco platform I introduced at the start of the series, describes a starting point this post would call settlements, processes scattered across “shared Excel spreadsheets, unstructured SharePoint folders and emails no one can trace”.

Since then, settlements have surfaced one at a time. In April 2026 a high-severity finding was documented. A regional BI dashboard was reading static Excel files kept in an analyst’s personal storage. The dashboard sat on formal ground, and what was informal was its source. The assignment of each customer to its KAM (the key account manager responsible for it) took a different path. It left the spreadsheets and moved into Datos Maestros (master data), which is now its source of truth and publishes it to the corporate data lake. That’s a relocation in this post’s sense, because the content changed buildings. Along the same lines, the expense master data formalizes tables that don’t exist in SAP, and dynamic catalogs replace scattered one-off catalogs.

Of the four responses, three show up, recognition, integration and relocation. What’s missing is exactly the step the method starts with. There’s no systematic inventory of settlements, and each one came to light through a finding or a migration. They don’t appear in the platform’s 3D model either, because its buildings are copied by hand from the tool registry and the RPA monitor, and those only list what’s already formal. Diveco reached its settlements in the reverse of the order this post proposes, response first and still no map. Without a map there’s also no settlement density to count, and that’s the variable P5 depends on.

What P5 predicts and how to test it

Proposition P5 holds that the density of informal settlements will be positively associated with duplicated data, hidden dependencies, control gaps and operational rework. These are forms of urban debt, the accumulated constraints that slow change and raise operational risk. Like the rest of the framework, P5 is an unmeasured hypothesis, and it comes with an indication of what evidence would test it.

If P5 holds, in a company like Northstar I’d expect districts with more settlements per capability to accumulate more manual reconciliations, more copies of the same data and more open control exceptions. Commercial, with the sheet and the app, would be the first place to look.

My own matrix has a trap here. If I score risk using the same consequences P5 predicts, the map can no longer test P5, because the association is already built into the measurement. Those consequences would have to be counted separately, from operational and audit records.

The most direct objection to the construct comes from the framework itself, and it’s a discriminant test. Settlement density has to separate empirically from conventional technical debt inventories, and if counting settlements turns out to be the same thing under another name, the construct is redundant.

Even if the association shows up, P5 doesn’t establish causal direction. It could be urban debt that pushes people to build outside, or a common cause, such as an underfunded platform team producing settlements and debt at the same time (platform funding is among the rival explanations). In either case, reducing settlements wouldn’t necessarily reduce debt. Rival explanations of this kind, and how a study could control for them, are the subject of how I would know this theory is wrong.

The experiments a registry prevents

Formalizing settlements improves governance and can suppress local experimentation. It’s the trade-off that comes with P5.

The field-visit app exists because a regional manager could build it without asking anyone’s permission. If the registry were a prerequisite, with architecture review and district approval, the app probably wouldn’t exist. The adoption it earned on its own, because it solved a problem its author lived with every day, is what I had to design on purpose in adoption engineering, with limits and deadlines enforced on the server. The cost of formalizing too early never shows up in an inventory, because it consists of tools that were never built.

There’s a second cost. A demanding registry is friction, and friction can produce the settlements the registry is supposed to govern, only better hidden this time.

To contain both, recognition comes after a settlement has shown value, never as a condition for building it. I reserve heavy treatment for settlements that touch customer data or move information out of the territory; the rest get registered with the minimum. Whoever built it takes part in the decision, because they usually know the capability it serves better than anyone.

The map has a cost too. It needs upkeep, it goes stale quickly and someone has to own it. A settlement inventory built once, in a spreadsheet, with no owner and no review date, meets the definition of an informal settlement.

What the map says about the formal city

Read as a negative, Northstar’s map describes its formal city, and the gaps it shows aren’t all of one kind. Two are Commercial capabilities the formal city wasn’t serving, exception-price approval and field-visit records. Another is an order route that was never built, for a capability no district claims. The last is an AI approval process nobody can complete in time. An application inventory wouldn’t have shown any of them, because it lists what the city built, and this map lists what people needed in the meantime.

There’s one condition no diagram solves. If the map is drawn by a team with no authority to change the formal city afterward, people learn that declaring a settlement only gets it taken away, and the next inventory comes back shorter than the first.

This article is part of the Digital urbanization series, based on the preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), a conceptual framework whose ideas I applied and refined on Grupo Diveco’s corporate platform, though its six propositions have not yet been empirically validated. Previous: Governing the data subsurface no one sees. Next: Digital habitability: what architecture doesn’t measure.