Why Technology Is an Institutional Problem

Efficiency can be bought. Judgment, recourse, and legitimacy have to be built.

Jul 01, 2026

A Digital Exam Became an Institutional Test

On February 9, 2026, the Central Board of Secondary Education told schools that Class XII answer books would be evaluated through an on-screen marking system.

The change was easy to describe as digitization. Physical answer books would be scanned. Examiners would mark them on screen. CBSE described the system as a way to reduce logistical delay, widen the pool of evaluators, reduce transport time and cost, and avoid common errors in totaling and transfer of marks.

The scale was large even by Indian administrative standards. According to reporting after the evaluation cycle, the system involved 98.66 lakh answer books, about 70,000 evaluators, more than 6,000 evaluation centers, and roughly 88,000 computers. This was not a small pilot that could be repaired through informal supervision. It was a national digital workflow for a high-stakes public examination.

No model was reading the answers. No algorithm was deciding a student’s marks. Human examiners remained formally in charge of evaluation.

The case matters because it shows that the institutional problem begins before AI enters the picture. Technology does not merely enter an institution. It reorganizes where institutions exercise judgment, what evidence can be seen, who can contest error, and how responsibility is distributed.

A paper answer book becomes a scan. An examiner now marks through a portal. A scan-related grievance becomes an online request inside a narrow window of time.

A student’s confidence in evaluation then depends on more than the examiner’s judgment. The examiner can judge only what the system shows. The student can contest only what the system reveals. The board can defend the process only if the digital workflow preserves evidence, authority, and credible recourse.

CBSE did not present the shift as an improvised change. Its circular referred to familiarization access, dry runs, training programs, a call center, and instructional videos. Later reporting also described dry runs, demonstrations, a webinar, and practice access before evaluation began. Those details matter because they show that the institutional question is not whether preparation existed at all. The harder question is what kind of preparation a digitized public workflow requires.

After the results, students and observers raised concerns about missing pages, missing supplementary sheets, blurred images, incorrectly mapped answer books, and the ability of students to verify what had actually been evaluated. CBSE later opened an online window from June 2 to June 6, 2026 for students who had obtained scanned answer books to apply for verification of scan-related issues and/or re-evaluation. The reportable scan issues included missing pages, missing maps or graphs, blurred pages, incorrect answer books, and evaluation against a different set.

The CBSE case also moved upstream into procurement. Sarthak Sidhant, a Class XII student, published a detailed comparison of tender documents and alleged that successive tender revisions softened a blacklisting clause, removed or diluted past-performance disqualifications, and lowered the required software-quality standard in ways that could have favored Coempt EduTeck. The Week reported that he presented these concerns before a Parliamentary standing committee, while The Indian Express reported that CBSE submitted its own response and said portal glitches had been rectified with additional time for re-evaluation applications.

The vendor and the board also pushed back. The Economic Times later reported that Coempt EduTeck defended the scanners used in the system as industry-grade and said records were open to scrutiny. The Times of India reported that CBSE described first-phase re-evaluation results as having been processed through a robust system, even as the board was consulting stakeholders before deciding whether to continue on-screen marking in 2027. A later Times of India report said CBSE stated it had cleared more than 99.7 percent of Class XII verification and re-evaluation cases while disputing a separate claim by Vedant Shrivastava about his own re-evaluation.

The reported error counts are therefore analytically awkward in the right way. About 20 answer-book mix-ups, 68,000 rescans, and more than 13,000 manually evaluated copies are small relative to nearly 10 million answer books. They are also not trivial for the students whose records were affected. High-stakes public systems are not judged only by aggregate error rates. They are judged by whether the institution can identify error, preserve evidence, explain authority, and correct harm without making the affected person carry the whole burden.

The CBSE case should therefore not be treated as an adjudicated failure or a settled case of wrongdoing. The factual record is still mixed: official releases, student allegations, vendor defense, committee attention, news reporting, and official response are all part of the story. The purpose here is not to decide legal responsibility. It is to see what the case reveals about digitized public systems under stress.

The relevant questions were not only whether scanned evaluation was faster or cheaper. They were whether the board had specified the system well, whether the vendor relationship preserved public control, whether students could see and contest the relevant record, whether error categories were anticipated, and whether redress had been designed before failure became public.

The system was digital. The stress points were institutional.

Figure 1: A digital workflow does not only change the medium of evaluation. It changes where judgment, evidence, authority, and recourse sit.

Human Judgment Still Needs Institutional Conditions

Digitization often presents itself as a way to remove friction from public systems. The older process is slow, dispersed, paper-based, and difficult to monitor. The newer process is faster, centralized, digital, and easier to standardize.

Often this is true. But efficiency is not the same as operational capacity.

Digitization is not only the conversion of paper into pixels. It requires complementary assets: reliable records, stable identifiers, clean metadata, trained users, role permissions, audit logs, exception categories, procurement standards, and grievance pathways.

Firms discover this when they try to add AI to messy internal workflows and realize that their institutional knowledge is scattered across emails, spreadsheets, local databases, and memory. Public agencies discover it when a digital workflow has to carry legal authority, citizen trust, and public accountability at scale.

Digital-government standards increasingly make the same point in institutional language. The UK’s Service Standard, the OECD’s Digital Government Policy Framework, and the World Bank’s GovTech Maturity Index all treat public digital systems as more than portals. They ask whether services are usable, secure, interoperable, operated well, and supported by operational capacity.

An on-screen marking system may reduce some errors while making other errors harder for ordinary users to see. A missing page in a physical answer book is one kind of problem. A missing page in a scanned bundle is another. A blurred image on a portal may still carry the authority of an official record. A digital interface can make a process look orderly even when the underlying chain of custody is contested.

Human judgment remains important, but the conditions under which judgment is exercised have changed. The public agency can defend the process only if it has retained enough control over scanning, indexing, logging, vendor performance, evidence preservation, and redress.

The bottleneck moves from marking to verification. Digital workflows can scale execution quickly, but recourse remains slower and more labor-intensive. The institution still has to prove that the record is complete, legible, traceable, and open to correction.

Digitization therefore does not remove institutional work. It redistributes it. Responsibilities that once sat with physical records, clerical checks, moderation routines, and inspection now sit with procurement specifications, workflow design, audit logs, portal architecture, and digital evidence.

Institutional judgment is relocated into the design of the workflow: what counts as a valid scan, what gets flagged before evaluation, who can see the original record, how quickly a student can object, what evidence is preserved, and who is accountable when the digital record differs from the material reality it was supposed to represent.

Software did not create this problem. James Scott showed how states govern by making society legible: through categories, records, and simplifications. Digital systems do not abolish those conditions. They formalize them, accelerate them, and sometimes make them harder to contest.

The institutional problem is not downstream of the technology. It is inside the technology’s use. The same software can produce different outcomes depending on the surrounding institution. In one setting, it may become a disciplined evaluation workflow with strong auditability and credible recourse. In another, it may become a fast and opaque system whose errors are visible only to those with the time, literacy, and confidence to challenge it.

Algorithms Formalize Institutional Assumptions

The CBSE case did not involve AI. Algorithmic systems reveal the same pattern more sharply because the institutional assumption is no longer only inside a workflow. It is also inside the model.

Institutional assumptions are the categories, proxies, and background judgments an organization treats as good enough for action: what counts as need, risk, eligibility, evidence, or success.

In the United States, a widely used health-care algorithm was found to underestimate the needs of Black patients. The problem was not that the model had been instructed to discriminate. It had used health-care spending as a proxy for medical need. Because Black patients had historically received less care for the same level of illness, lower spending made them appear less sick to the system.

The technical problem mattered. But the deeper issue sat in the proxy and the setting that made it plausible.

The model converted a social and institutional history into a decision rule. Unequal access to care became lower recorded expenditure. Lower recorded expenditure became lower predicted risk. Lower predicted risk meant fewer Black patients were identified for additional care-management support. For an affected patient, the problem was not experienced as an abstract proxy error. It meant being less likely to be routed toward extra help.

The problem was detected because researchers compared the model’s risk scores with direct measures of illness rather than accepting spending as the ground truth. When the objective shifted toward predicting health needs instead of future costs, the racial disparity fell sharply. The repair was not only technical. It required asking what institutional assumption the proxy had carried into the model.

In both examples, technology becomes consequential through the categories, proxies, workflows, and accountability structures around it. While the CBSE case asks whether an institution can specify, monitor, audit, and correct a high-stakes digital workflow, the health-care algorithm adds a sharper lesson: AI can turn an institutional assumption into an operational routine. A proxy choice becomes an allocation pathway, and the assumption becomes harder to contest once it is embedded in the model.

Categories Decide What Counts as Governance

Whether a system is described as digitization, automation, artificial intelligence, or public infrastructure is not just a semantic issue. The category determines what kind of scrutiny the system receives. It shapes which experts are invited, which rules are applied, which failures are anticipated, and which forms of accountability become visible.

Institutions often govern categories before they govern technologies.

The CBSE dispute shows how much follows from the category. CBSE introduced on-screen marking as a logistics and efficiency upgrade. Students, observers, and parliamentary attention made it legible as something larger: a high-stakes digital evaluation and procurement system. Under the first category, the main questions are speed, cost, and administrative convenience. Under the second, different questions appear: scan integrity, data custody, vendor accountability, examiner workflow, appeal design, and the evidentiary rights of students.

A logistics upgrade is judged by efficiency and cost. A governance mechanism also has to be judged by legitimacy, equity, and recourse.

The system need not be AI to require digital governance.

Similarly, if a health-care algorithm is treated only as an efficiency tool, its proxy choices may appear technical. If it is treated as an institutional allocation mechanism, those same choices become questions of fairness, access, and responsibility.

Public debate often begins after a system has already been categorized too narrowly. By then, the institutional questions have been framed as implementation details.

A system’s category is already a policy decision. It allocates authority, defines the problem, and determines whether a failure is treated as a software issue, a procurement issue, a rights issue, a capacity issue, or a governance issue. In practice, it is often all of these.

The Operating Layer Has Four Parts

The institutional life of technology usually becomes visible in four places: procurement, workflow, oversight, and recourse.

Procurement decides what the public agency has actually bought. It determines the vendor’s obligations, the standards to which the system is held, the audit rights retained by the state, the security expectations, the ownership of data, and the remedies available when performance breaks down.

Workflow decides how the technology enters routine practice. It determines who uses the system, what they see, when they can intervene in real time, what gets logged, and which exceptions are escalated. A workflow can make human judgment more disciplined. It can also make human judgment more dependent on what the system chooses to display.

Oversight decides whether the institution can look back at what the system did after deployment. It determines whether logs are useful for review, whether failures are sampled or investigated, whether audit rights can be exercised, and whether performance claims can be tested against real use.

Recourse decides whether affected people can challenge the system in a meaningful way. It determines whether a student can see the relevant record, whether a patient can understand the basis of a decision, whether a citizen can correct an error, and whether the institution can repair damage without forcing the burden entirely onto the user.

Procurement, workflow, oversight, and recourse are not external safeguards added after deployment. They are part of the technology’s institutional form. Many policy debates become too thin because they ask only whether a technology should be adopted, regulated, banned, subsidized, or scaled. Those are important questions, but they are not enough. The same technology can produce different outcomes depending on the contract, the workflow, the audit process, and the grievance system around it.

The operating layer is where digital governance becomes real. Accountability, learning, and the distribution of authority are decided here, often before the public debate has named them. A public agency may retain formal authority while operational knowledge shifts to a vendor. A citizen may retain a formal right of appeal while the evidence needed to exercise that right sits inside a portal. An organization may announce a feedback process while the system lacks a routine for turning failures into revised standards.

The institutional problem stops being abstract at this operating layer.

Operational Capacity Is AI Capability gives this ability its more precise name: operational capacity. It is the capacity to perform this institutional work repeatedly. A capable institution does not merely buy a system. It knows how to specify what it needs and evaluate what it receives. It can test behavior, monitor failures, preserve evidence, revise workflows, and build credible recourse without surrendering judgment to the vendor, the interface, or the claim of efficiency.

Without that capacity, an institution may adopt the same system and still lose control of the function it was trying to improve.

The difference is not the technology alone. It is the surrounding operational capacity to make the technology answerable to public purpose.

IndiaAI Makes Operational Capacity Strategic

Public systems have always relied on categories, records, procedures, and delegated judgment. What is new is the pressure. AI systems can classify, rank, predict, and recommend at scales that make ordinary administrative review difficult. They can also make dependence harder to see, because the system presents itself as a usable interface rather than as a chain of assumptions, vendors, data, incentives, and constraints.

India’s AI policy ecosystem is trying to operate across this chain rather than only at the level of adoption. The IndiaAI Mission is a serious attempt to build multiple layers at once: compute capacity, datasets, application development, skilling, startup financing, and Safe and Trusted AI are all part of the same mission architecture. Later official releases on the IndiaAI Compute Portal and AIKosha and an AI Safety Institute add operational texture. The Mission is addressing real access constraints around compute, datasets, models, and safety tools. These are necessary foundations. But access expands the opportunity set; operational capacity determines whether those assets become durable capability inside real institutions. The institutional question is whether those assets are surrounded by standards, testing routines, procurement templates, incident reporting, and public-sector practice.

The eight Responsible AI projects selected under the Safe and Trusted AI pillar should be read inside this larger architecture, not as the whole Mission. Policy direction becomes operational capacity only when tools for audit, privacy, bias mitigation, explainability, certification, and governance testing enter the routines of hospitals, school boards, welfare agencies, regulators, and public procurement teams. That is the difference between passive procurement and operational capacity. A safety tool that remains a research output is not the same as an assurance system that institutions can use repeatedly under pressure.

The bridge between the CBSE case and IndiaAI is not that every digital workflow is secretly an AI system. It is that AI will make the same institutional questions harder, more urgent, and more consequential.

A ministry can procure AI tools without developing the capacity to audit models, evaluate proxies, protect data, or design recourse. A university can deploy automated systems without understanding how they reshape teaching, assessment, and student trust. A hospital can use prediction without asking how past inequality enters the data and how present judgment should respond.

The issue is not whether institutions use technology. They already do. The question is whether the work around that use becomes explicit, repeatable, and accountable.

For middle powers and developing societies, this is especially important. They are often encouraged to adopt frontier tools quickly, build digital platforms, and demonstrate technological modernity. But the harder work is less visible. It lies in procurement competence, technical state capacity, public-sector learning, standards, auditability, domain expertise, and credible channels of correction.

The strategic question is whether institutions can turn technological opportunity into durable capability. Operational capacity, sustained over time, is one way capability formation becomes real.

Figure 2: Technology becomes durable capability only when institutions can specify, oversee, contest, and repair its use.

Technology Is Only as Capable as the Institution Around It

The lesson from the CBSE case is not that digital evaluation should be rejected. The lesson from the health-care algorithm is not that prediction should never be used. The lesson from IndiaAI is not that policy missions are insufficient because they do not solve everything immediately.

The lesson is that technology reorganizes the institutional problem: where judgment is exercised, who can see error, how responsibility is distributed, and what counts as evidence.

When operational capacity is weak, technology can make a system look more modern while making accountability more fragile. When operational capacity is strong, technology can make a system faster, more legible, and more reliable.

The central question is not simply what the technology can do. It is what the institution is capable of doing with it.

Efficiency can be purchased. Technology can be procured. Judgment has to be built.

A note of Caution on the CBSE case: the OSM controversy is still evolving. This essay does not adjudicate legal responsibility, vendor liability, or the full factual record. It uses the case to examine what digitized public systems reveal under stress.

Visual note: The diagrams in this essay are original Yukti visuals, designed from the author’s briefs and produced with AI-assisted code generation, then reviewed before publication.

Discussion about this post

Ready for more?