When Government Becomes Invisible

But what if digital public services were organized around life events rather than agencies?

You could start with one simple statement:

“I moved to a new address.”

A future digital service could securely verify your identity, determine which participating services may be affected, show you exactly what needs to change and—with your permission—help complete those updates.

You remain in control. But instead of navigating the structure of government, technology handles much of that complexity behind the scenes.

This isn't starting from zero. Government agencies already use digital identity services to verify that someone accessing a sensitive online service is really who they claim to be.

For example, someone applying online for unemployment benefits through the Virginia Employment Commission can use ID.me for identity verification and subsequently access claim information, upload documents and respond to requests.

The IRS also uses ID.me for identity verification and access to many online services. Once an individual's identity has been verified, the same ID.me account can be used to access multiple IRS services rather than repeating the entire identity-proofing process each time.

More broadly, identity verification can work alongside fraud-detection and risk-analysis systems that compare information against trusted data sources and identify suspicious patterns

The objective isn't merely easier login. Strong identity verification can help prevent someone from impersonating another person to obtain benefits, access sensitive information or conduct other protected transactions.

So some of the building blocks of future digital government already exist. The larger opportunity is making identity increasingly secure, reusable, interoperable and privacy-conscious across digital services.

A physical identity document often reveals much more information than a particular transaction requires. To prove that you meet an age requirement, for example, you might present an identification card containing your full name, photograph, exact date of birth, address and identification number.

But the organization may need to know only one thing:

“Does this person meet the required age?"

A privacy-conscious digital credential could potentially answer Yes without disclosing all of the additional information printed on the underlying document.

The same principle could apply to residency, driving privileges, professional qualifications and other verified attributes.

This is an important distinction. The future of digital identity isn't simply about replacing a physical card with a digital copy on a phone. It could allow people to prove what is necessary for a transaction while revealing less unnecessary personal information.

• “I lost my job."
• “I'm starting a small business.”
• “My father passed away.”
• “I bought a car.”
• “I'm moving to another state.”

Not every question should be answered by AI from its general training alone.

Government services can involve taxes, benefits, licenses, deadlines, eligibility requirements and other matters where incorrect information can have real consequences.

A more reliable approach is for AI to retrieve information from authorized and current sources—such as regulations, policies, program rules, official guidance, agency systems and, where permitted, the individual's own records—and then use that information to explain the answer in understandable language.

For important information, the person should also be able to see the underlying source rather than being expected to trust the AI blindly.

A stronger model therefore looks like:

Natural conversation → Authoritative information → Secure personal context when authorized → Clear explanation → Source visibility → Human escalation when needed

In this model, AI isn't the authority. It becomes an intelligent interface to authoritative information and services.

AI doesn't have to replace traditional websites, mobile apps, search, forms or other digital channels. Those interfaces can remain useful—especially when someone already knows exactly what they need.

A person who knows the task might simply select:

"Renew Vehicle Registration"

But someone beginning with an unfamiliar situation might say:

“I just moved here. What do I need to do?”

Both experiences can ultimately reach the same underlying services and systems. The difference is how the person begins the journey.

AI therefore becomes** another entry point,** not necessarily a replacement for every existing interface.

The larger change is from:

Understand our organization → Find the correct service

to:

Tell us what you need → We'll help you navigate the organization

When a document enters a process, several things may need to happen before anyone can act on it.

The document must be identified. Relevant information must be located and extracted. Required fields may need to be checked. Information may need to be compared with other authorized records. Missing or inconsistent information may need to be identified. Finally, the document has to be routed to the appropriate next step.

Traditionally, much of this work has required manual review.

Intelligent document processing could increasingly turn that sequence into an automated workflow:

Document received → Identify document type → Extract relevant information → Validate required fields → Compare against authorized data → Detect missing or unusual information → Continue routine processing or route an exception to an employee

The important change isn't simply converting words on a page into digital text.

It is understanding enough about the document to help determine what should happen next.

Automation doesn't need to successfully handle every possible situation to provide significant value.

Imagine thousands of documents entering a process. Many may be complete, readable and routine. Others may contain missing information, conflicting data, unusual circumstances or content the system cannot interpret confidently.

Instead of requiring employees to review every document in exactly the same way, intelligent processing could separate routine work from cases that genuinely require attention.

Routine case:
Complete → Validated → Continue processing

Exception:
Missing information → Conflicting information → Low confidence → Employee review

This changes the employee's role from:

“Review everything.”

to:

“Focus attention where human judgement is needed.”

The objective isn't to remove people from the process. It is to avoid spending human attention on predictable work that technology can handle reliably, while making sure uncertain or consequential situations reach the appropriate person.

The benefits of intelligent document processing aren't limited to internal efficiency. They can directly affect the citizen's experience.

Better document processing could mean fewer requests for information already submitted, faster identification of missing documents, quicker processing of routine transactions, less manual data entry and earlier notification when something needs attention.

Instead of submitting an application and waiting days or weeks to discover that something is missing, a future service might respond almost immediately:

“We received your application and three supporting documents. One required document is still missing. Here's what you need to provide.”

The difference is significant. Rather than discovering problems late in the process, technology can help identify them while the person still has an opportunity to correct them quickly.

Some of the most valuable digital improvements may therefore happen behind the screen—in processes the citizen never sees directly.

Today, many public services begin only after a person realizes that something needs to be done.

A driver's license is approaching expiration. A benefit must be renewed. A tax deadline is coming. A family moves to a new address. The individual is expected to recognize the requirement, remember the deadline, locate the appropriate service and complete the necessary steps.

Connected digital services could gradually move this experience through three stages:

Reactive

Person discovers a need → Finds the appropriate service → Starts the process

Proactive

An upcoming requirement is identified → Person receives a timely notification → Relevant service is provided

Intelligent Assistance

A life event or changing circumstance occurs → Authorized systems identify potentially affected services → Person reviews the options → Approved actions move forward

Consider something simple such as a driver's license approaching expiration. Instead of relying entirely on the individual to remember, a digital service could provide a secure notification well in advance, explain what is required and provide a direct path to renewal.

The more significant opportunity comes when one event affects several services at the same time. A move, job loss, birth, retirement or death in the family can create multiple responsibilities that people currently have to discover and coordinate themselves.

Proactive government doesn't necessarily mean government taking action without permission. It can mean recognizing a potential need earlier, explaining the available options and allowing the individual to decide what happens next.

A more proactive service model shouldn't mean that government automatically makes decisions or changes records simply because a system detects that something may have happened.

There is an important difference between:

“You may qualify for this service. Would you like to learn more?”

and:

“We made this decision for you.”

When personal information is used to anticipate a need, people should be able to understand what information is being used, why it is relevant, which organizations are involved and what action is being proposed.

Depending on the service, the person may also need to provide consent before information is shared or an action is completed.

A well-designed proactive service could therefore work more like:

Recognize a potential need → Explain why → Present relevant options → Ask for authorization when required → Complete the approved action

This keeps the convenience of proactive assistance while preserving an essential principle: the person should remain informed and appropriately in control.

Much of this architecture already exists behind everyday digital experiences.

Consider something as ordinary as placing an order online. To the customer, the experience may appear simple:

Choose product → Place order → Receive confirmation

Behind that single action, however, many independent capabilities may be working together:

Customer account → Inventory → Payment → Fraud checks → Tax calculation → Warehouse → Shipping → Notifications

These capabilities don't necessarily run inside one enormous application or share one database. Different systems can perform specialized functions and communicate through APIs, messages and other integration technologies.

The customer doesn't need to know which system verifies the payment, where inventory is stored or which service generates the shipping notification. The technology coordinates those activities and presents them as one understandable experience.

This illustrates an important principle for the future of public services:

A simple experience for the user doesn't require a simple system behind the scenes.

Government could apply the same architectural principle while dealing with additional requirements around privacy, security, legal authority, accessibility and accountability.

One of the technologies that makes connected digital services possible is the API—Application Programming Interface.

An API provides a controlled way for one application to request information or a service from another application.

At its simplest:

Application A → API → Application B

The two applications don't have to use the same programming language, database or internal architecture. Each system can continue performing its own specialized function while exposing only the capabilities that other authorized systems are allowed to use.

For example, one system might need to know whether a professional license is currently valid. Instead of receiving the licensing agency's entire database, it could make an authorized request:

“Is this credential currently valid?”

and receive:

“Valid: Yes”

This is an important distinction. Connected systems don't necessarily mean centralized data. Systems can remain independently managed while securely exchanging specific information or requesting specific services when needed.

This loosely coupled approach also allows technology to evolve gradually. An older system, a modern cloud application and a new AI-powered service could potentially participate in the same broader digital experience through well-designed integration layers.

Government can build on many of the same technology principles already used across banking, healthcare, retail, transportation and other industries. The additional challenge is that public services often cross organizational boundaries.

Individual agencies may operate specialized systems for taxes, transportation, licensing, benefits, public safety or other responsibilities. At the same time, governments may provide shared technology capabilities such as networks, cybersecurity, cloud services, identity services and integration platforms.

A connected digital experience doesn't require replacing all of those systems with one enormous government application.

Instead, specialized systems can remain responsible for their own functions while secure integration allows authorized services to work together when necessary.

Imagine again that someone says:

“I moved to a new address.”

Behind one simple experience, several capabilities could potentially participate:

Digital identity → AI understands the request → Workflow identifies affected services → Secure APIs connect authorized systems → Individual agency systems perform their responsibilities → Citizen sees one coordinated experience

From the citizen's perspective, it can feel like one service.

Behind the scenes, it may still involve many independently managed systems, technologies and organizations.

That is the larger architectural idea:

Many systems. Many responsibilities. One understandable experience.

A useful example can be found in Virginia. Individual state agencies operate systems supporting their own missions, while the Virginia Information Technologies Agency (VITA) provides statewide technology governance, standards and enterprise technology services across the Commonwealth.

This illustrates an important principle: shared technology doesn't require every agency to operate the same business application.

An agency responsible for transportation, taxation, licensing or benefits may still need specialized systems designed around its particular responsibilities. At the same time, enterprise capabilities can support areas such as infrastructure, cybersecurity, connectivity and other shared technology needs.

Future digital services could build on this model by making it easier for authorized systems to interact through common standards, APIs and shared capabilities.

The objective isn't:

One enormous system that does everything

It is:

Specialized systems + shared capabilities + secure connections → coordinated services

Virginia is only one example. The same architectural principle can apply across governments—and, more broadly, across large organizations where many independent systems must work together.

Discussions about digital transformation often create the impression that older systems must be replaced before meaningful innovation can happen. In practice, modernization can be more gradual.

A system may be decades old and still perform an important business function reliably. The immediate challenge may not be its age—it may be that the system was designed to operate largely on its own.

APIs, integration services and other architectural layers can sometimes allow existing systems to participate in newer digital experiences without exposing their internal complexity directly to citizens or other applications.

A modernization path might therefore look like:

Existing business system → Integration layer → Secure API → Modern digital service

Over time, individual components can be improved or replaced as business needs, risks and costs justify the change.

This also reduces the temptation to treat every modernization effort as one enormous replacement project.

Age alone doesn't determine whether a system should be replaced immediately. The more important questions include whether it remains secure, reliable, maintainable, supported and capable of meeting current and future service needs.

Modernization can therefore mean connecting, simplifying and gradually improving systems—not simply replacing everything at once.

New technology can improve a service, but it cannot automatically fix a poorly designed process.

Moving an application to the cloud may improve scalability or infrastructure management, but the service can still contain unnecessary forms, duplicate data entry and complicated approval steps.

Adding automation can make a workflow faster—but if the workflow contains unnecessary steps, technology may simply perform those unnecessary steps faster.

The same is true for AI. Adding an AI assistant to a confusing process doesn't necessarily make the underlying service better.

A stronger approach begins with the service itself:

Understand the problem → Simplify the process → Determine what information is actually necessary → Connect the appropriate systems → Automate predictable work → Apply AI where it adds meaningful value

Sometimes the most valuable modernization decision may be removing a step, eliminating duplicate information or changing a business process rather than introducing another technology.

Digital transformation isn't about using the newest technology everywhere. It is about using technology deliberately to create a better outcome.

Consider a hypothetical example: an employee responsible for reviewing 150 cases..

After automated validation and initial processing, the workload might look something like this:

**112 cases **— Complete and routine
**18 cases **— Missing required information
**9 cases **— Conflicting information
**6 cases **— Unusual circumstances
**5 cases **— Require judgement or further investigation

These numbers are only illustrative, but the principle is important.

Instead of an employee manually performing the same checks on all 150 cases, technology could handle predictable steps and direct attention toward the cases that actually require it.

The employee's workload changes from:

Process every case → Find the exceptions

to:

Review exceptions → Resolve problems → Apply judgement → Help people

Automation would still require controls. Routine cases may need sampling, auditing and monitoring to make sure automated processing continues to produce accurate results.

The goal isn't simply to process more work with fewer people. It is to use human expertise where it provides the greatest value.

Automation can make an existing process faster. But before automating it, there is another question worth asking:

Should the process work this way at all?

A workflow may have accumulated forms, approvals, data fields and handoffs over many years. Some may still be necessary because of law, policy, security or operational requirements. Others may exist largely because “that's how we've always done it.”

Before automating a process, organizations can ask:

Why are we collecting this information?
Does another authorized system already have it?
Why does this step require manual review?
Is this approval still necessary?
Why is the same information entered more than once?
Which requirements are legally necessary, and which are simply historical process choices?

This is where employees become especially important. The people who perform the work every day often know where delays occur, which steps create confusion and which repetitive activities provide little value.

Digital transformation works best when technology is combined with process improvement and employee knowledge.

Otherwise, an organization risks doing something very efficiently that didn't need to be done in the first place.

As routine work becomes increasingly automated, the nature of some public-sector jobs could change.

Employees may spend less time on repetitive processing and more time on work such as:

Resolving exceptions — handling cases that don't follow predictable rules
Applying judgement — interpreting complicated or unusual circumstances
Investigating problems — examining conflicting information or potential errors
Helping people — explaining requirements and resolving difficult situations
Monitoring automated systems— identifying errors, unexpected outcomes and process failures
Reviewing AI-supported work — verifying recommendations when decisions have meaningful consequences
Improving processes — identifying unnecessary steps and better ways to deliver services

AI and automation can also create new responsibilities. Someone must determine whether automated workflows are producing the intended results, whether AI-generated information is accurate, whether exceptions are being handled appropriately and whether people are being treated consistently.

This means the future workforce may need a different mix of skills—not only technical expertise, but also critical thinking, communication, domain knowledge, problem-solving and the ability to work effectively with automated systems.

A useful way to think about the relationship is:

Automation → Handles predictable work
AI → Helps understand, organize and assist
People → Apply judgement, accountability and human understanding

The objective is to move human attention up the value chain, away from repetitive activity and toward work where people provide something technology cannot reliably provide on its own.

Connected systems can make services more convenient, but the ability to access information doesn't automatically mean that every service should receive all of it.

A stronger principle is data minimization: use only the information necessary for the specific purpose.

If a service needs to know whether someone meets an age requirement, it may not need the person's exact date of birth. If it needs to verify residency, it may not need access to unrelated records. If another agency has already verified a credential, a service may need only confirmation that the credential is valid.

This creates an important distinction:

“What information do we have?”

is very different from:

“What information does this service actually need?”

Privacy-conscious digital services should also make it clear why information is being requested, how it will be used, when authorization is required and which organizations are involved.

Technologies such as digital credentials and attribute verification could further reduce unnecessary disclosure by allowing a system to confirm a fact without always transferring the underlying record.

The future of connected government shouldn't be based on making every piece of information available everywhere. It should be based on making the right information available for the right purpose, with appropriate authority and safeguards.

As public services become more connected, cybersecurity becomes more important at every layer of the experience.

Protecting a digital service isn't only about securing the website someone sees. Security may need to extend across:

Identity and authentication — Is the person really who they claim to be?

Applications — Are the systems protected against unauthorized access and manipulation?

APIs and integrations — Can systems exchange information securely, and are requests properly authorized?

Data — Is sensitive information protected while stored and while moving between systems?

Infrastructure — Are networks, cloud platforms, servers and supporting services appropriately secured?

Monitoring and response — Can suspicious activity, compromised accounts or unusual system behavior be detected and addressed?

Greater connectivity can improve the citizen experience, but it can also increase the potential impact of a security failure. A weakness in one component may affect services beyond that individual system.

This is why cybersecurity cannot simply be added at the end of a modernization project.

Security has to be part of the architecture, the development process, the operational environment and the ongoing management of the service.

The objective isn't to eliminate every possible risk—no digital system can promise that. It is to understand the risks, reduce them appropriately, detect problems quickly and limit the impact when something does go wrong.

One of automation's greatest advantages is scale. A well-designed system can perform the same routine task consistently across thousands or even millions of transactions.

But scale works in both directions.

If a business rule is incorrect, important data is incomplete, an integration sends the wrong information or an AI model behaves unexpectedly, automation can repeat the same problem across many cases before someone notices.

That means monitoring automated services requires more than asking:

“Is the system running?”

Organizations also need to ask:

“Is the system producing the right outcomes?”

This can require reviewing samples of automated decisions, monitoring unusual patterns, measuring error rates, investigating complaints and comparing results across different groups and circumstances.

Automated systems should also provide ways to trace what happened: which information was used, which rules or models were involved, what action occurred and when human intervention took place.

When something does go wrong, organizations need the ability to identify affected cases, correct the underlying problem and reconsider decisions when appropriate.

Automation doesn't remove accountability. At scale, it makes accountability even more important.

Discussions about AI often focus on whether an algorithm might produce biased results. That is an important concern, but unfair outcomes can enter a process long before an AI model becomes involved.

Bias or unequal outcomes can potentially come from:

Historical data — Past records may reflect earlier policies, practices or inequalities.

Incomplete data — Important circumstances may be missing from the information available to the system.

Business rules — A rule that appears neutral may affect different groups or situations differently.

Problem definition — What an organization chooses to predict, optimize or automate can influence the outcome.

Model behavior — An AI or statistical model may perform differently across populations or circumstances.

Human interpretation — People can also apply rules inconsistently or bring assumptions into decisions.

Responsible automation therefore requires looking at the entire decision process, not simply testing the AI component in isolation.

When a decision significantly affects someone's rights, benefits, obligations or access to a service, there should also be an appropriate way to question or correct the result.

A useful principle is:

Automated result → Understand the reason → Correct inaccurate information → Request human review when appropriate

Technology can support more consistent decisions, but consistency alone doesn't guarantee fairness. Organizations still need to examine how decisions are made, what information influences them and what happens when the system gets something wrong.

A digital service can be fast and convenient for many people while still creating barriers for others.

People may have limited internet access, difficulty using digital technology, disabilities that affect how they interact with a service, limited English proficiency or circumstances that simply don't fit neatly into an automated process.

Accessibility therefore needs to be part of service design from the beginning—not something added after a system has already been built.

AI could potentially improve accessibility in some areas. It may help explain complicated information in simpler language, support conversational interaction, translate content or help people navigate unfamiliar services.

But technology can also create new barriers if it becomes the only way to obtain assistance.

A well-designed digital service should provide appropriate alternatives:

Self-service when it works → Assisted digital support when help is needed → Human service when the situation requires it

The objective isn't to force everyone through the same channel. It is to make routine services easier while ensuring that people who need additional assistance aren't left behind.

Digital first can improve convenience. Digital only can create exclusion.

Responsible innovation doesn't mean avoiding new technology until every possible risk has disappeared. That would make meaningful improvement extremely difficult.

It means introducing new capabilities in a way that allows organizations to learn before expanding them broadly.

A practical approach might look like:

Experiment → Pilot → Measure → Identify risks → Improve → Expand

An organization might begin with a limited use case where the consequences of an error are manageable. It can then evaluate whether the technology actually improves the service, identify unexpected problems, gather feedback from citizens and employees, strengthen safeguards and decide whether broader deployment is justified.

The questions shouldn't focus only on whether the technology works:

Did it improve the experience?
Did it reduce unnecessary effort?
Were the results accurate and consistent?
Did employees encounter new problems?
Did some people experience barriers others didn't?
Were privacy and security protections effective?
Could people understand what happened and obtain help when necessary?

Innovation therefore becomes a continuous cycle rather than a one-time technology project.

Try something useful. Measure what actually happens. Learn from the results. Improve it. Expand only when the evidence supports doing so.

When a service is slow or difficult to use, it can be tempting to begin with a technology:

“Can we use AI?”
“Can we automate this?”
“Should we move it to the cloud?”

A better starting point is:

“What problem are we actually trying to solve?”

Imagine a service takes an average of 20 days to complete. Before selecting a technology, the organization needs to understand where those 20 days come from.

Perhaps applications frequently arrive incomplete. Maybe employees re-enter information from documents. A case might wait several days between organizational handoffs. The same information may be verified more than once. Or employees may spend significant time searching across systems before they can act.

Each problem could require a different solution.

Missing information → Better guidance or earlier validation
Manual data entry → Document intelligence or system integration
Repeated information → Authorized data reuse
Long handoffs → Workflow redesign and automation
Difficulty finding information → Search or AI-assisted knowledge tools
Unnecessary approval → Process simplification

In some cases, the best solution may involve AI. In others, it may be an API, a redesigned form, clearer instructions—or simply eliminating a step that no longer provides value.

Innovation should begin with understanding the problem. Technology comes afterward.

A technology improvement rarely matters because of the technology alone. Its real value often appears through a chain of effects.

Consider intelligent document processing:

Better document understanding → Less manual data entry → Missing information identified earlier → Fewer cases waiting unnecessarily → Faster processing → Fewer status inquiries → More employee time for complex cases

The first improvement is technical, but the later effects are operational and human.

The same thinking can be applied to other technologies:

Better system integration → Less duplicate information → Fewer citizen inputs → Simpler transactions

AI-assisted knowledge search → Less employee search time → Faster answers → Shorter interactions

Earlier digital validation → Fewer incomplete applications → Less rework → Faster decisions

This is why measuring only whether a new system was delivered can miss much of the story.

A useful measurement chain is:

Technology capability → Process improvement → Operational outcome → Citizen or employee outcome → Public value

The farther an organization can follow that chain, the better it can understand whether an innovation actually made a meaningful difference.

Technology teams naturally measure things such as system availability, API response times, transaction volumes, error rates and infrastructure performance. Those measures are important—but they don't necessarily reveal whether the service is working well for the people using it.

A system might report 99.9% availability and still provide a frustrating experience...

An API can respond in milliseconds while an application waits several days for a manual approval.

A digital portal can process thousands of transactions while a significant number of people abandon the process before completing it.

The citizen experiences the entire journey, not the individual technology components behind it.

That means service measurement should also ask questions such as:

Could people find the correct service?
Could they understand what was required?
How many successfully completed the process?
Where did people abandon it?
How often was additional information requested?
How long did the complete journey take?
How often did someone need to contact an employee for help?

The same principle applies internally. A new system may reduce one employee's workload while quietly shifting additional work to another team.

This is why employee feedback matters alongside technical metrics and citizen outcomes. The people performing the work can often identify problems that dashboards alone won't reveal.

A healthy system is important. A successful service is the larger goal.

Large-scale transformation doesn't always need to begin with a large-scale deployment.

A focused pilot can test whether an idea actually improves a service before it is expanded more broadly.

A practical approach might look like:

Identify the problem → Establish a baseline → Test a limited solution → Measure the results → Gather feedback → Correct problems → Expand when justified

The baseline is especially important. Without knowing how the service performs today, it becomes difficult to determine whether a new technology actually made things better.

Suppose a pilot is intended to reduce incomplete applications. Before introducing the change, the organization could measure how often applications arrive incomplete, how much employee time is spent requesting additional information and how much delay that creates.

After the pilot, those same measures can be compared.

Did incomplete applications decrease?
Did processing become faster?
Did employees spend less time on rework?
Did citizens find the new process easier?
Did the change create any unexpected problems?

If the results are positive, the approach can be refined and expanded. If they aren't, the organization has learned something valuable before committing to a much larger implementation.

This also changes how innovation is viewed. A pilot that reveals an idea doesn't work as expected isn't necessarily a failure. Discovering that early—while the scope is limited—can prevent a much larger and more expensive mistake.

Innovation doesn't always require artificial intelligence, a new cloud platform or a major system replacement.

Sometimes the most valuable improvement is much simpler.

A confusing application might need clearer language. A process may contain an approval that no longer serves a useful purpose. Two systems may be asking people for the same information when an existing API could securely provide it. A commonly misunderstood requirement might be solved with better instructions at the beginning of the process.

In those situations, introducing more technology could actually add complexity rather than remove it.

This is why modernization should remain focused on the outcome:

What are we trying to make easier, faster, safer or more reliable?

The answer might be AI.

It might be automation.

It might be better system integration.

Or it might simply be removing something that never needed to be there.

The most innovative solution isn't necessarily the one using the newest technology. It is the one that solves the problem effectively.

During this imagined day, the person never needs to think about APIs, cloud platforms, document-processing models, workflow engines or the databases behind individual services.

Yet many technologies may be working together:

Digital identity establishes who the person is.

AI helps understand what the person is trying to accomplish and explains relevant information.

Connected services and APIs allow authorized systems to exchange specific information and perform specialized functions.

Document intelligence extracts and validates information from submitted documents.

Automation handles predictable steps and routine processing.

Data and business rules help determine what information is required and what should happen next.

Human expertise takes over when circumstances require judgement, investigation, explanation or accountability.

The important part is that the person doesn't experience these as seven separate technologies.

They experience:

“I needed something done, and the service helped me accomplish it.”

That may be one of the clearest signs of successful digital transformation: the technology becomes less visible while the service becomes easier to understand.

or decades, digital government has largely meant creating better interfaces: websites, portals, mobile apps, online forms and dashboards.

Those interfaces will continue to matter. But as systems become more connected and intelligent, some of the best digital experiences may require less interaction rather than more.

A person may not need to search for a service if a relevant need can be identified at the appropriate time. They may not need to complete another form if authorized information is already available. They may not need to repeatedly check a status page if the service can notify them when something meaningful changes.

In that sense, government doesn't literally become invisible.

The responsibility remains visible. The decisions remain accountable. The use of personal information remains transparent. And people must still be able to reach another person when necessary.

What becomes less visible is the unnecessary complexity:

Which agency handles this?
Which website do I need?
Which form should I complete?
Why am I entering this information again?
Who do I contact to find out what happened?

The future of digital public services may therefore be measured partly by how much of that complexity people no longer have to experience.

Government doesn't disappear. The bureaucracy surrounding the experience begins to fade into the background.

NIST — Digital Identity Guidelines
Guidance for digital identity, identity proofing, authentication and federation.
https://csrc.nist.gov/pubs/sp/800/63/4/final

NIST — Artificial Intelligence Risk Management Framework (AI RMF)
A framework for managing risks associated with AI systems, including reliability, transparency, accountability and human oversight.
https://www.nist.gov/itl/ai-risk-management-framework

NIST — Generative AI Profile
Guidance addressing risks specific to generative AI, including confabulation, information integrity, human-AI interaction and responsible use.
https://doi.org/10.6028/NIST.AI.600-1

OECD — Digital Government Outlook 2026
Research on human-centered digital government, proactive public services, digital identity, data sharing and the evolution of government service delivery.
https://www.oecd.org/en/publications/digital-government-outlook_0496b2bc-en.html

OECD — Governing with Artificial Intelligence
Research and examples examining how governments are adopting AI and the governance needed for responsible use.
https://www.oecd.org/en/publications/governing-with-artificial-intelligence_795de142-en.html

Virginia Information Technologies Agency (VITA) — Enterprise Architecture
Virginia's framework for enterprise technology standards, governance, interoperability and shared technology capabilities.
https://www.vita.virginia.gov/policy--governance/enterprise-architecture/

Virginia Employment Commission — Unemployment Benefits
Current information on digital unemployment services and the use of ID.me for online identity verification.
https://www.vec.virginia.gov/apply-unemployment-benefits

Internal Revenue Service — Online Account and Identity Verification
Current information about IRS online accounts and the use of ID.me to verify identity for online services.
https://www.irs.gov/help/creating-an-account-for-irsgov