Superintelligence in the Public Sector

Superintelligence in the public sector is still a hypothesis, not something an agency can buy today. What civil servants face in practice are increasingly capable AI models, and the rules that apply are the familiar ones: legality, transparency, data protection and accountability for whoever decides. The central point is to keep the decision human, recorded and explainable, even as the tools become more powerful.

Key takeaways

• Superintelligence is a concept under debate. Today's risks and obligations come from generative AI and AI agents, and those are what a civil servant actually decides about.
• Transparency is not optional in the public sector: citizens and oversight bodies must be able to understand when and how AI took part in an official act.
• Brazil's data protection law (LGPD) applies to public authorities, with a defined public purpose, data minimization, security and the right to review automated decisions.
• Administrative accountability does not pass to the vendor or to the model. Whoever signs the act answers for it.
• Starting with one small workflow, with limits, logs and an agreed success metric, reduces risk and produces evidence to decide whether to expand, adjust or stop.

What does superintelligence mean for a public agency?

In the literature on the topic, superintelligence describes a system that would outperform humans in practically every relevant cognitive task. It does not exist as a product. To understand where the debate comes from, read the summary of Nick Bostrom's Superintelligence and what managers can take from it, and the explanation of why ChatGPT is not superintelligence.

For a civil servant, the useful question is a different one: what happens to public accountability as tools become more capable? A model that writes well, summarizes long case files and acts in systems through integrations makes it tempting to accept the output without checking it. The risk grows precisely with the apparent quality of the answer.

It helps to separate three layers, as we do in any technical text:

• Official documentation: what the law, the data protection authority (ANPD) and recognized guidelines say. This is the basis for obligations.
• Implementation experience: what tends to work and fail when AI is placed in a real workflow. This is guidance, not a rule.
• Hypothesis: what might happen with far more capable systems. It serves planning, not the justification of today's decisions.

Mixing these layers is the most common mistake in presentations to managers. A vendor promising "almost human intelligence" is offering a hypothesis as if it were documentation.

Transparency: what citizens and oversight bodies must be able to know

The principles of public administration (legality, impersonality, morality, publicity and efficiency) do not make an exception for technology. If AI takes part in an official act, it must be possible to reconstruct the path: what information went in, who reviewed it, who decided and on what grounds.

In practice, this means three safeguards:

• Clear notice to citizens when they are talking to an automated assistant, including on channels such as WhatsApp, and an option to reach a person.
• A usage register: which workflows use AI, for what purpose, with which data and under which unit's responsibility.
• The ability to answer information requests and audits, which requires preserved logs and plain language, not only technical reports.

The OECD AI Principles treat transparency, explainability and accountability as pillars of trustworthy AI. The NIST AI Risk Management Framework organizes risk management into the functions of governing, mapping, measuring and managing. Neither replaces Brazilian law, but both help build governance that an internal control office can examine.

A frequent mistake is to treat the model as a black box and settle for "the system recommended it". For an administrative act, the reasoning must be human and verifiable. If the civil servant cannot explain why the suggestion was accepted, transparency has failed, even if the vendor delivers an attractive dashboard.

LGPD in the public sector: purpose, necessity and review

The LGPD reaches public authorities and sets specific rules for how they process data. Processing must serve a public purpose, within legal competences, and the situations in which it occurs must be clearly disclosed. The general principles still apply: purpose, adequacy, necessity, transparency, security, prevention and accountability.

For anyone evaluating AI, this translates into direct questions:

• Which personal data does the workflow really need? Pasting an entire case file into a chat tool when an excerpt would do goes against the idea of necessity.
• Where does the data go? AI services often process information outside the country. The article on international data transfer when using AI providers under the LGPD covers this point in detail.
• Was the data protection officer consulted before use, and is there an impact assessment when the risk justifies it?
• Does the vendor contract define roles, retention, use of data for training and incident response?

There is also the right to review decisions made solely through automated processing that affect the data subject's interests. This is explained in LGPD automated decision-making and the right to review. In the public sector the practical consequence is simple: do not let AI alone conclude anything that grants, denies, punishes or classifies a citizen.

For official guidance, the starting point is the ANPD website. As for a specific AI law, the safest path is to follow the legislative process and regulation, as we summarize in Brazil AI regulation: what companies should watch and do now, without treating a text under debate as a binding obligation.

Who is accountable when AI gets it wrong? Responsibility and human decision

Administrative responsibility falls on the public official who performs or validates the act and on the authority who approves the use of the tool. Saying "the model made a mistake" is no justification, just as "the spreadsheet made a mistake" would not be. The vendor may answer contractually for its own failures, but public competence remains with the agency.

That is why the human decision must be real, not a rubber stamp. Three signs show it has become a rubber stamp:

• The reviewer receives more volume than they can check with care.
• The interface shows only the AI's conclusion, without the sources or passages that support it.
• Nobody records disagreements, so no one knows how often the AI is corrected.

A division of roles helps. AI can summarize, classify for triage, suggest a draft and locate internal rules. The civil servant decides, gives the grounds and signs. When the system gains autonomy to act (sending messages, changing records, opening cases), permissions should be minimal, with human approval for irreversible actions or those affecting someone's rights. The OWASP Top 10 for LLM applications lists concrete risks, such as prompt injection through text the model reads and excessive agency, which matter a great deal when the system reads documents submitted by third parties.

One governance principle sums it up: the more capable the tool, the sooner the agency should define who can switch it off, who receives alerts and how an act taken with its support is reversed.

Checklist for adopting AI in an agency without losing control

The method we apply in AI projects for companies also works as a skeleton for the public sector, respecting its own procurement and oversight rules: map, limit, pilot and hand over. In steps:

• Map: describe the current workflow, who does what, which data circulates and what the starting point is (response time, rework, complaints). Without this picture, there is no way to say later whether AI helped.
• Map: classify the workflow by its impact on citizens. Informational service and internal summaries carry a different risk from benefit analysis or inspection.
• Limit: define which data the AI can see, which actions it can perform and what it must refuse. Sensitive data and decisions affecting rights stay out of the initial scope.
• Limit: formalize the legal basis, the purpose, the data protection officer's role and the contract clauses on retention, training and data location.
• Pilot: choose a single real workflow, with logs of input, output, sources consulted and human review, and a success metric agreed before starting.
• Pilot: test with hard cases and with attempts to push the system into error, using repeatable evaluations, not the impression of whoever tested it.
• Hand over: give operation to the agency's team with documentation, named owners, a monitoring routine and a criterion for deciding whether to expand, adjust or end.

If the agency prefers to keep data under local control, it can evaluate models run on its own infrastructure, a topic covered in running Ollama local models in a company. The choice depends on security, available staff and need, not on fashion.

Illustrative scenario: triaging requests in a service channel

Illustrative scenario: a municipal department receives requests for document copies, questions about deadlines and service requests by message. Today, staff read everything and forward it manually.

The agency maps the workflow and defines the pilot: an assistant that identifies the type of request, answers questions based on an official guidance page and forwards the rest to a human queue. It does not assess the merits of any request, does not ask for sensitive documents and states at the start that this is an automated service, with the option to speak to a person.

The limits are written down: a list of permitted topics, a standard reply for anything out of scope and immediate handoff when the citizen reports urgency or a serious complaint. Each conversation produces a record with the classification made and the source used. A civil servant reviews a weekly sample and notes the corrections.

At the end of the pilot, the team compares results with the initial picture and with the metric agreed beforehand. If classification went wrong in sensitive cases, it adjusts the rules or narrows the scope. If the result was good, it expands to another type of request, keeping the same discipline. The design of the messaging service can draw on the practices described in how to integrate AI into your company's WhatsApp, adapted to public sector requirements.

The example is hypothetical and does not represent the result of any agency. It shows the format: narrow scope, minimal data, a human in command and evidence to decide the next step.

Frequently asked questions

Does superintelligence already exist in the public sector? No. What exists are increasingly capable AI models and agents, which already require governance. Treating the subject as a future hypothesis does not excuse the agency from meeting today's rules on transparency, data protection and accountability.

Can a civil servant use a public chatbot to summarize case files? It depends on the agency's policy and the data involved. Personal, confidential or third-party data should not be pasted into tools without a contract, a legal basis and an assessment by the data protection officer. The safest approach is a clear internal rule on what can and cannot be sent.

Can AI decide a citizen's request? For acts that grant, deny or classify rights, the decision must be human, reasoned and open to review. AI can support with a summary or triage, but the responsible civil servant must check the sources and take ownership of the act. This protects both the citizen and the public official.

Where should an agency start? By mapping a small, low-impact workflow, with minimal data, logs and a success metric defined beforehand. After the pilot, the team decides on evidence whether to expand, adjust or stop. Along the way, it is worth involving the data protection officer, internal control and the legal department early.

Sources

• NIST AI Risk Management Framework
• OECD AI Principles
• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP Top 10 for LLM Applications