Dependence, Control, and the Coming Age of AI Reliance
What stays with me about HAL 9000 is how much of the spaceship he can see, hear, and control.
The crew of the Discovery One relies on him for essential operations. When that relationship breaks down and HAL faces being disconnected, he acts against the people who depend on him.
That is the part of 2001: A Space Odyssey I keep returning to: the combination of broad access, operational power, and dependence. By the time the crew needs to take control back, doing so is dangerous.
I read the film as a warning about what happens when a system becomes essential without a workable plan for operating around it. That interpretation is what interests me in today's business use of AI.
What We're Actually Building
For today's businesses, the practical parallel is the amount of work and control we place around AI systems. That dependence is something we can examine and plan for without assuming that a model has HAL's fictional motives.
Organizations are connecting agents to documents, databases, communications, and operational tools. Each connection can make an agent more useful. It also creates questions about what the system can access, what it can change, and how people would continue if it stopped working.
The risks I want a business to consider include:
- Losing the ability to carry out a critical process without an external model
- Giving an agent more access or authority than its task requires
- Relying on outputs people do not know how to check
- Building workflows whose operating costs are poorly understood
- Leaving responsibility unclear when something goes wrong
Those are practical design questions, even when the model itself has no independent control over the organization.
The Business Version of the Problem
You build the workflows, connect the agents, organize the data, and make the system part of everyday operations. At the end of the month, there is an OpenAI bill, an Anthropic bill, or another provider's bill behind that work.
My concern is what happens as dependence grows. If a provider changes pricing, access, behavior, or availability, how easily can the business respond?
Competition can give customers alternatives. But an alternative existing does not mean a company can switch overnight. The integration, prompts, evaluations, and operational habits may all have been built around a particular model.
That is the leverage I am concerned about. Its extent depends on the provider's terms, the alternatives available, and the cost of switching. I want to understand those tradeoffs before a service becomes essential.
The Transparency Problem
For a consequential workflow, I want the people responsible to be able to inspect what happened: which sources were used, what the agent produced, what tools ran, and what changed as a result.
Those records do not reveal every internal mechanism of a model. They can still provide evidence for reviewing a decision, investigating a failure, and improving the system.
Useful practices include:
- Recording the inputs, source references, outputs, and tool actions needed to investigate important outcomes
- Restricting access to those records and avoiding unnecessary sensitive data
- Building human review into consequential decisions
- Defining when uncertainty or a failed check should trigger escalation
- Preserving the expertise needed to recognize a bad result
The aim is to make the workflow understandable enough that accountability does not disappear behind the word "AI."
The Dependency Problem
This is where a backup plan matters.
If a model service becomes unavailable, changes, or grows too expensive, can the business still serve a customer, answer an important question, or finish a critical task?
A fallback might be a manual process, direct access to existing reports, a queue that keeps work safe until service returns, or an alternative model that has actually been tested. The right option depends on the task.
Having another API key is not the same as having a working backup. The replacement needs the necessary connections and context, and people need to know when and how to use it.
I also think operating funds belong in this discussion. Understand the recurring model costs, set usage limits where appropriate, and maintain enough budget or reserves to support the workflows the business relies on. An impressive system is not operationally sound if nobody has planned how to keep it running.
The Accountability Gap
Responsibility should be discussed before a failure.
Who owns the workflow? Who checks its quality? Who can pause it? Who responds when a provider is unavailable or an action produces the wrong result?
Those are decisions the organization can make explicitly. Provider contracts and applicable requirements also need attention, but a contract does not replace an internal owner who understands the process.
For me, the useful question is whether the people involved know what they are responsible for and what to do when the system needs intervention.
What Good Looks Like
The safeguards I want are practical:
- Clear scope: Give the agent the access and authority its task needs.
- Reviewable outcomes: Keep enough evidence to check consequential work.
- Human direction: Ask for input when a decision needs judgment or affects the project's goals.
- A tested fallback: Know how essential work continues during a disruption.
- An accountable owner: Make responsibility and escalation clear.
- A sustainable budget: Understand recurring costs and plan for changes in usage or service.
The HAL parallel is a reminder to stay conscious of dependence as we build. I want AI to extend what people can do while preserving their ability to understand the work, intervene, and choose another path when needed.