The bridge applied to the public sector

A person requests a medical appointment from their phone. They fill in their details, get a confirmation and trust that the system will sort out demand. They do not know whether behind it there is a simple rule, a predictive model or an agent combining information from several sources, and there is no reason they should have to know. What they need is to be seen within a reasonable time and, if the appointment never comes, an explanation.

In another office, a public employee looks at a list of prioritized cases. She knows the neighborhood, knows that some addresses get entered wrong and suspects that part of the information arrives late. The system shows her an order, but does not explain how much each piece of data weighed or what she should do when her experience contradicts the ranking. If she follows the list and someone is left out, who answers for it? If she changes it, will her judgment be recognized or will it look like a deviation?

The modernization of the State happens in the space between those two people. It is more than swapping paper for screens or adding AI to a case file: it changes the way an institution recognizes a need, allocates resources and justifies its decisions. That is why, on this ground, the method keeps its structure (read before automating, govern before scaling) and raises its demands.

In a business, as the SME chapter showed, a poorly designed system can cost sales, time and trust: serious harms. In the public sector it can also obstruct access to health care, education, security or social protection. The person affected did not choose the platform and rarely has an alternative provider. They depend on the quality with which the State designed the system that serves them.

The difference is measured in rights. Auditability, fairness, avenues of appeal and accountability stop being optional virtues: they are part of the legitimacy of the intervention.

The procedure seen from both sides

Every public procedure has at least two stories. One is institutional: it starts in one department, goes through certain checks and ends in a resolution. The other belongs to whoever needs to get something done, who may have to gather documents the State itself already holds, travel, wait, decipher technical language and come back because an exception was not foreseen.

Digitizing only the first story can leave all the friction of the second one intact. The form becomes electronic but still asks for the same certificates; the queue turns into a wait with no information; the counter disappears and, with it, the person who used to help interpret an ambiguous requirement.

Sociotechnical diagnosis reconstructs both stories at once. It reviews the formal case file and follows the real journey. It asks who decides, who waits, where the same data gets entered twice and who gives up before finishing. It also looks at the civil servant, because many workarounds that look like bureaucracy from the outside serve a purpose: they make up for incomplete data, handle exceptions or protect the agency from a poorly defined responsibility.

The goal is to tell apart the control that protects a right from the step that survives out of inertia. Automating both alike makes more efficient a mixture that first needed to be separated.

That reading may show that the main obstacle is not the visible system. Perhaps two agencies do not share information, a regulation requires a signature that no longer adds any control, or the team keeps a parallel database because the official record does not reflect urgency. Before offering AI, one has to decide whether the problem calls for interoperability, regulatory simplification, role redesign or a combination.

The citizen is not just any captive user

Product design talks a lot about user experience. In the State, the word “user” can hide a political relationship. Someone applying for a right is not picking an app the way a consumer would: they are a citizen facing an institution that exercises power and has obligations.

That asymmetry changes the bar. In a private service, an awkward interface can push a person toward a competitor. In a mandatory procedure, the same awkwardness becomes a barrier. And if it falls disproportionately on older people, on those living in areas with poor connectivity or on citizens with disabilities, the usability problem becomes a fairness problem.

Multichannel access responds to that reality. A digital service can be the main channel without being the only one: when a procedure affects rights and part of the population cannot complete it any other way, there has to be help by phone, in person or at support points. Keeping an alternative channel is a recognition that the digital transition takes place in an unequal society, which does not mean giving up on modernization.

Quality has to be measured by group and territory. An overall completion rate can improve while it worsens in neighborhoods with weaker connectivity. A lower average time can hide the fact that complex cases are stuck. Publishing and reviewing those differences shows whether aggregate efficiency is closing gaps or widening them.

Finally, there has to be an understandable path of appeal. If an automated decision denies a benefit or changes a priority, the person needs to know that a system was involved, what relevant information was considered and how to request a review. The explanation does not need to expose source code or overwhelm anyone with mathematics. It has to let them understand the reason, correct a piece of data and get an answer from someone accountable.

The civil servant as a bearer of judgment

The automation story tends to present the public employee as a layer of friction that technology should remove. That picture ignores a decisive part of the job. In many services, the civil servant interprets general rules in situations that do not fit, recognizes urgency and connects information that lives in separate systems. Part of that capability can be formalized; another part is tacit knowledge built up through practice.

A serious intervention does not assume, either, that all existing judgment is sound. There may be arbitrariness, favoritism, needless habits and redundant controls. That is precisely why judgment has to be observed and discussed before it is automated: a bad practice that gets encoded gains scale and an appearance of objectivity that is hard to challenge.

Well designed, AI works as an extension of the civil servant’s judgment: it summarizes case files, flags missing information, finds similar cases or prioritizes a review. For that help not to turn into blind substitution, the workflow has to make clear which part is a recommendation, what its limits are and at what point the person can step in. → Authors and currents.

Adding a signature at the end is not enough to ensure human control. If volume, incentives or the interface mean that no one actually reviews, the signature legitimizes an automated decision without contributing any judgment. Design has to reserve human attention for cases that are uncertain, high impact or hard to reverse, and give the reviewer enough information and time.

It also has to protect permission to disagree. A civil servant who corrects the system may be adding context or repeating a bias. Both possibilities call for a record and a review, and neither side deserves automatic obedience. When disagreements are documented, the organization can learn which rules need adjusting and where discretion causes harm.

What a purchase cannot deliver

The State usually relates to technology through procurement. It is a necessary route for obtaining goods and services, but it can feed an illusion: that institutional capability comes bundled with the license.

A vendor can build software, integrate systems and contribute specialized knowledge. What it cannot do is decide on the institution’s behalf what an administrative category means, what level of error is acceptable or how a public decision is appealed. Nor should it become the only place where the model, the data or the architecture are understood. If the contract ends and the agency cannot audit, maintain or retire the solution, modernization has left a dependency behind.

That is why the pre-purchase verdict reviews more than features and price. It asks about ownership of and access to custom-built code, data export, documentation, component licenses, the handling of personal information, digital signature and the exit plan. The bridge does not replace legal analysis; it makes legal questions come up while they can still change the architecture and the contract.

What this book calls technological lock-in is dependence on a vendor that makes leaving costly or impossible, and in the State it has a democratic dimension. If switching vendors becomes materially impossible, a private company gains power over the continuity of a public service. That dependence can shape costs, the system’s evolution and the capacity to be held accountable. Designing an exit is an act of institutional responsibility that does not presuppose distrust of the vendor.

Nor does the purchase solve internal fragmentation. A new system can add yet another island if agencies do not agree on identifiers, responsibilities and legal bases for sharing data. Interoperability, properly understood, enables the flow that is needed, with purpose, minimization, security and traceability, instead of connecting every database without limits.

Public data: sharing without exposing

The State holds sensitive information and, at the same time, has to coordinate policies that cut across agencies. Health, education, housing and social protection may describe different aspects of the same situation. Being unable to link them produces repeated procedures and partial decisions; linking them indiscriminately produces surveillance and the risk of secondary uses.

Governance has to resolve that tension case by case. What is the purpose? What legal basis allows the processing? Which data are strictly necessary? How long are they kept? Who has access, and how is that recorded? Could the same goal be achieved with less identifiable information?

These questions come before the code. A privacy impact assessment or an algorithmic impact assessment should not be written afterward to justify a finished solution. Its value lies in changing decisions: reducing data, modifying the model, adding a review channel or dropping a use case whose benefit does not outweigh the risk.

Data quality also has a public dimension. Administrative records were not always created to train models: they reflect data-entry criteria, uneven coverage and historical decisions. A missing value may mean that something did not happen or that a territory was observed less. Without understanding how the record was produced, the system learns the footprint of the administration and mistakes it for reality.

Cathy O’Neil documented how opaque models used at scale can hide and reproduce harm under a mathematical appearance.¹ In the State that risk is especially serious, because the rule can be repeated across entire populations and because those who bear the error usually have fewer resources to contest it. Auditability makes it possible to reconstruct what happened; participation and prior assessment help keep it from happening.

The smart city after the demo

Urban projects show the distance between technology and capability with particular clarity. Sensors are installed, a control room is inaugurated and a map shows incidents in real time. The demo works. Value, however, only appears when the data enters a loop of action.

A sensor that detects a pothole does not fix the street. Someone has to know which department receives the alert, how it prioritizes it, what budget it uses and how it reports that the issue was resolved. If the data ends up on a screen that no one can turn into a work order, the infrastructure produces visibility without service.

The eternal pilot is a common form of that failure. It stays at a protected scale, with vendor attention and hand-picked staff, and never goes through the ordinary processes of budgeting, maintenance and accountability. Every year it is presented as innovation, and every year it dodges the question of how to integrate it.

Sustainability requires looking at the full cycle: energy, connectivity, equipment replacement, maintenance and final disposal. An environmental promise cannot rest only on the fact that the solution uses data. It has to show what consumption it avoids, what infrastructure it adds and what concrete action closes the loop. Otherwise the smart city becomes technological stage scenery.

Govern before scaling

Current frameworks offer a common language for these obligations. The NIST AI Risk Management Framework organizes the work into four functions: govern, map, measure and manage. Govern runs through the other three, because owners, policies and accountability mechanisms are not added at the end.²

The European Union’s Artificial Intelligence Act classifies systems by risk and sets requirements for traceability and human oversight in high-impact uses.³ Its legal reach does not turn every provision into an automatic local obligation, but it marks a relevant regulatory direction: the greater the effect on people, the greater the capacity to explain, record and control has to be.

The OECD examined around two hundred AI cases in government functions and organized them around enablers, guardrails and engagement.⁴ That structure matches a sociotechnical reading. Capabilities and data enable; impact assessment and auditing protect; engagement brings in those who live with the consequences.

For Latin America, the Latin American Artificial Intelligence Index (ILIA), by CEPAL and CENIA, is the regional reference: its 2025 edition covers nineteen countries and distinguishes pioneer, adopter and explorer ecosystems.⁵ The comparison brings capabilities and gaps into view without assuming that the institutional context of better-resourced countries can be copied intact.

IMIA translates part of these demands into an organizational reading. Its governance gate (a capping rule) keeps a high score in technology or data from hiding an insufficient capacity to answer for the system. The principle is simple: an organization is not ready for autonomy it cannot yet govern.

When the agent exercises part of the power

Agentic systems make this problem more visible. Software that prioritizes case files, routes cases or allocates resources can carry out many intermediate decisions without a person reviewing each one. Human control then shifts toward rules, permissions and audit mechanisms: judgment comes to be exercised in the design rather than in every transaction.

That shift makes control even more important. It has to be defined what the agent resolves, which actions are off limits to it, when it must escalate to a person, what information it keeps and how its access is revoked. It must also be possible to reconstruct the sequence after an error. When several agents and services interact, a final explanation without traceability can hide where the decision that mattered was actually made.

Delegating an administrative task is not delegating public responsibility. The institution remains obliged to understand the system well enough to supervise it and answer for it. A contract that assigns every failure to the vendor does not repair the right that was affected or restore legitimacy.

In high-impact decisions, part of the design has to remain deliberately human. People are not infallible, but public power needs an identifiable place where reasons can be debated and an exception can receive judgment. Automating routine work can free up time for that task if the organization protects it; the gain can also be used to cut staff and reduce review capacity. Technology does not choose between those two paths.

Institutional capability, not a catalog of tools

Public modernization in Latin America is not bought as a package. It is built with understood processes, governed data, sustainable infrastructure, capable civil servants and avenues for participation and redress.⁶ A tender can supply important pieces, but the coherence among them has to be produced by the institution.

The bridge applied to the State starts from the citizen’s experience and returns to it to measure. Besides asking whether a procedure is available online, it asks who manages to complete it, how long they wait, what happens when there is an exception and how a decision can be contested. It evaluates a model by its accuracy, but also by the distribution of its errors, its traceability and its capacity for correction. And it measures transformation by the quality of the public action the systems make possible, more than by the systems installed.

The medical appointment scene brings the journey to a close. A good system can sort demand, detect urgency and shorten waits. To do so legitimately, it has to acknowledge incomplete data, let the employee add context, inform the person and offer a review when something fails. Efficiency and rights are not opposing goals, and sociotechnical design exists so that neither is pursued as if the other were not part of the system.

See also: The bridge applied to SMEs · IMIA, the maturity instrument · The bridge thesis · Authors and currents · Bibliography