Superintelligence will not sign the discharge summary

For a regulated enterprise, superintelligence arrives one workflow at a time, as domain superintelligence (SI): a system built to work at expert level inside one bounded workflow, with the audit trail, integration and human accountability that a regulated enterprise needs. It changes what a system can do inside that workflow and leaves unchanged who answers for what it did. Clinical accountability, DPDP 2023 obligations and the duty to reconstruct a decision stay with named people and organisations, so the useful move for a CTO today is to build the layer that holds accountability, audit and integration, and to build it to survive every model upgrade.

The labs have named the goal

Superintelligence stopped being a science-fiction word in 2025, when the companies building frontier models started using it as their stated objective. Sam Altman wrote in June 2025 that OpenAI is, "before anything else", a superintelligence research company (Source: Sam Altman, "The Gentle Singularity", 10 June 2025). Mark Zuckerberg created Meta Superintelligence Labs by internal memo on 30 June 2025 (Source: CNBC, 30 June 2025). Microsoft formed an MAI Superintelligence Team under Mustafa Suleyman in November 2025, framed as "humanist superintelligence" (Source: CNBC, 6 November 2025).

The market has started to blur three terms, so this piece keeps them apart. AI means the systems running in production today: the models, agents and pipelines drafting notes, answering calls and reviewing documents inside hospitals and pharma companies. General superintelligence is what the labs are chasing, a system that outperforms the best human experts across most cognitive work. Nobody has shipped one. Domain superintelligence (SI) is the narrow version: a system built to work at expert level inside one bounded workflow, wired into the systems that workflow already runs on, with a named person who answers for its output.

Only the third term belongs in a regulated enterprise's planning, because only the third can be scoped, integrated and audited. So the question for a hospital CIO is practical: as systems are built toward expert level on more narrow workflows, what holds?

What more capability does not move

Three things stay where they are, however capable the system becomes.

Accountability. Our reading is that clinical judgment sits with the clinician and, vicariously, with the hospital, and we know of no CDSCO or NMC pathway that transfers it to a software company. A more capable model does not create one. The question to take to your counsel is where that accountability sits for each workflow you automate. Suppose a domain SI system drafts discharge summaries. A registered doctor still signs each one, and on our reading the liability attaches to that signature, which is the point to confirm with counsel. In pharma, a pharmacovigilance narrative, an MLR decision and a regulatory submission each have a named owner who answers to the regulator.

Data obligations. Under DPDP 2023, the hospital or the pharma company is ordinarily the Data Fiduciary, and consent, purpose limitation and breach duties follow the organisation that holds the patient relationship, whichever model processes the data. Ask counsel to confirm that allocation for each deployment. A more capable model performs better with more context, and the law still limits what you may give it.

Reconstruction. None of this allocation is enforceable unless you can reconstruct what happened: which input, which retrieved record, which model version, which prompt, which human action. That requirement runs through the direction of Indian policy. The MeitY AI Governance Guidelines of November 2025 state that DPDP 2023, the IT Act, consumer protection law and sector regulators already apply to AI. The Principal Scientific Adviser's white paper of January 2026, "Strengthening AI Governance Through Techno-Legal Framework", argues for building compliance into the design of AI systems from the start. Neither makes an exception for very capable systems.

Why more capability raises the stakes on the layer around the model

Vendor demos imply that as models get smarter, the scaffolding around them matters less. In a regulated enterprise the opposite holds, for three reasons.

Delegation grows with capability. A model that drafts gets reviewed line by line. A system built to work at expert level gets reviewed by exception. As capability rises, enterprises hand over larger decisions, and an unreconstructable decision becomes proportionally more expensive. The value of the audit trail grows with the model it sits around.

Review fatigue grows with accuracy. When a system is right almost every time, the people reviewing it stop reading. A clinician who signs an ambient note unread has taken operational control of an unverified output, and that failure becomes more likely as the model improves. Domain SI makes this sharper, because a system designed to work at expert level gives the reviewer a reason to skim. The fix is structural. Sample outputs for full review, force review on high-risk decision classes, and capture every override so that a pattern shows up before an incident does.

Model turnover outpaces validation. Model generations now turn over faster than a hospital's procurement and validation cycles. Every model swap is a change to a validated workflow, and a workflow validated on last quarter's model says nothing certain about this quarter's. Without versioned models and prompts and a regression set to test the new version against, every upgrade is an unvalidated change in a regulated process.

What to build now that holds either way

Six pieces keep their value whether the next model is a small step or a large one.

1. An audit trail you own. For every consequential output, keep the input, the retrieved context, the model and prompt version, the output and the human action taken on it. Store it in your environment, readable without the vendor's help.
2. Model-agnostic integration. Connect to the HMIS, the LIMS and the safety database through open APIs and MCP servers you control, so that swapping a model is mostly a configuration change. The integration layer outlasts every model you will run on top of it.
3. An intended-use statement per workflow. Name the decision class the system supports, the class it must not touch, and the human step in between. Revisit it whenever the model changes, because a more capable system will be tempted into neighbouring decisions nobody signed off.
4. Human review designed for fatigue. Build the sampling, the forced-review triggers and the override capture described above. Assume the reviewer will eventually stop reading.
5. A regression set per workflow. Keep a fixed set of real cases, with expected outputs agreed by the people who own the decision, and run every model change against it before go-live. We will say plainly where Nextdot stands: observability (audit logs, versioned models and prompts, override capture) runs on every deployment we operate. Formal evaluation against clinician-labelled ground truth does not yet run on every account, and extending it is a current engineering priority. Ask every vendor the same question, and expect an answer as specific as that.
6. An exit plan from any single model. If your workflow can run on only one provider's model, the provider's roadmap has become your compliance roadmap. Keep the option to move.

What to stop doing

Stop buying on the next model's demo. A capability demo shows what a model can do on a good day. The test that predicts whether a deployment survives is whether the vendor can show you the last thirty overrides and explain each one. In most hospitals with an incumbent AI vendor, nobody can.

Stop deferring process fixes to a smarter model. A more capable model reading a broken HL7 v2 feed produces a confident answer about the wrong patient. Integration debt, unclear ownership and missing intended-use statements get more expensive as models improve, because the output they corrupt gets more persuasive.

Stop contracting on a label. "Superintelligence" with no workflow attached cannot be scoped, so it has no place in a contract. A domain SI system can be contracted because it is bounded: name the workflow, the intended use, the regression set and the person who signs off. Put those into the contract alongside accuracy thresholds for the stated intended use, an SLA, and who carries which failure class.

Where domain superintelligence (SI) fits at Nextdot

Nextdot builds AI systems for regulated enterprises, and domain SI is the name we use for what we build: systems designed to work at expert level inside one bounded workflow at a hospital group or a pharma company, integrated with the systems that workflow runs on, and logged so outputs can be traced. General superintelligence remains the labs' question. Ours is narrower, and it describes the direction each system is built toward and the layer that has to surround it.

The term always travels with the accountability that sits beside it. However capable the system becomes on its one workflow, the discharge summary will still carry a doctor's name above the signature line. Build for that doctor.

Frequently asked questions