Mountain View, California, is Google’s hometown. You might expect a city with that address to be reasonably acquainted with software.
In May 2024, its City Council approved Flock Safety’s license-plate cameras. The police department worked with the company to establish sensible restrictions: no out-of-state sharing, and no outside agency admitted without approval from the chief or someone the chief designated.
There was considerable care in the arrangement. Unfortunately, some of it remained in the arrangement.
A department audit found a statewide search function open on 29 of the 30 cameras. California agencies that had not received permission could search Mountain View’s data. The department disabled that setting on January 5, 2026.
One camera had also been open to nationwide searches from August to November 2024. Several federal law enforcement agencies accessed it.
The department had not been shown these lookup functions during onboarding. No one has been able to establish how the settings were enabled.
An onboarding presentation can be perfectly clear about everything it contains. The difficulty begins with what it leaves out.
On February 2, 2026, Police Chief Mike Canfield shut off all 30 cameras. “I personally no longer have confidence in this particular vendor,” he said. On February 24, the City Council voted unanimously to end the contract.
The restrictions had survived. The relationship had not.
The restrictions had survived. The relationship had not.
Sources: City of Mountain View; Mountain View Voice; Palo Alto Daily Post.
AI drift debt starts with what the approval could not establish
Mountain View’s first camera went live on August 14, 2024. The final installation occurred in January 2026. Earlier audits, conducted at random intervals, missed the unauthorized access. A later network audit found it.
That distinction matters. The department was checking. Its checks were failing to answer a consequential question.
The public record also leaves open whether the original configuration ever matched the agreement. We should be careful about calling something a change when we have not established its starting condition.
I call AI drift debt the accumulated cost of assuming that the alignment built at the start of an AI initiative will hold on its own.
Mountain View illustrates the danger of allowing the agreement and the operation to go unreconciled. A business also needs evidence that its starting point existed outside the paperwork.
Otherwise, the baseline records what everyone meant to buy.
Your vendor has continued working since the meeting
Your team approves an AI tool. Someone records its purpose, permissions, and limits. The document goes into a sensible folder.
Meanwhile, the supplier continues developing the product.
A feature might arrive. A human review might become optional. Someone might begin using the same application for a different job because it is already available and the budget meeting is next month.
Each change can have an explanation. The explanations may be scattered among people who have not spoken to one another.
Release notes offer one opportunity to keep up. They also offer the comforting possibility of confusing receipt with readership.
Terms can change, too. On July 1, 2026, HubSpot announced changes concerning customers who opted into data enrichment. On July 5, it withdrew them and apologized: “That’s on us and we are sorry.”
A customer returning from a few days away could have found both an announcement and its withdrawal waiting in the inbox. Keeping up would have required reading them in the correct order.
That episode concerns a withdrawn proposal. It does not establish 4 days of changed product behavior. It does show how much can happen between the occasion when you approve a service and the occasion when you next examine it.
What does yours do today?
A review needs somewhere to send the answer
In federal IT, I led a change control board. Every week, at least one request arrived without enough definition, an upstream governance review, or a testing plan.
It went back to its sender.
The prospect of presenting a request to a committee did not automatically improve it. Having a committee willing to return it did.
A smaller business can establish that responsibility without arranging a weekly gathering large enough to require refreshments. Someone needs to examine the evidence, and someone needs authority to decide what happens when it fails to match the agreement.
The following activity draws on the NIST AI Risk Management Framework’s guidance on ongoing review, clear responsibilities, and change management. The 4 steps and 6 Change Triggers are my adaptation.
4 steps between approval and the next surprise
Pick 1 AI tool and bring together its regular users and the system owner. In a smaller business, the owner may be you.
Using AI now: begin with the tool whose vendor emails go unread.
New to AI: complete Steps 1 and 2 during setup, and ask which controls can change later.
1. A regular user records what the tool does
The record covers:
- What goes in
- What comes out
- Who sees the results
- Which settings matter
The regular user and system owner inspect the configuration itself. For access controls they cannot see, the owner asks the vendor for confirmation and available access records.
An unanswered question stays unanswered in the record. It does not become an assurance because everyone would prefer to finish the meeting.
The owner signs off on what has been verified. That becomes the baseline.
2. The system owner assigns someone to each trigger
The owner and regular users agree who watches for each of these 6 Change Triggers and who receives the report:
- Purpose: the team uses the application for a new job.
- Autonomy: someone loosens a human check, such as allowing replies to go out without review.
- Data: the inputs or their destination change.
- Supplier: the vendor updates a feature, setting, or terms.
- Jurisdiction: a new law applies, or the business starts working in another state or country.
- People affected: the system reaches new customers, employees, or applicants.
Everyone using it should know whom to tell when its behavior changes. Finding the right person should not require a second investigation.
3. The system owner schedules regular comparisons
The review happens on a recurring schedule, such as monthly or quarterly, and whenever a trigger fires.
The owner and regular users compare the baseline with current settings, observed results, available access records, and unresolved vendor questions. They mark every difference.
This is repetitive work. Repetition is useful here: a vendor update or a change in model behavior does not have to produce a complaint before it deserves examination.
4. The authorized person makes the decision
During setup, the owner records who can authorize continued use and who can order a pause.
At each review, that person chooses: keep, adjust, pause, or retire. The record includes the reason and required follow-up.
The baseline changes after approval. An unexplained difference remains open.
Rewriting the record to match an unexplained configuration would make the next comparison easier. It would also dispose of the question you assembled everyone to answer.
Different
Different
Sources: City of Mountain View; The Record; Palo Alto Daily Post.
What will the next review find?
Mountain View had restrictions, onboarding, and periodic audits. The unauthorized access survived those precautions until a different examination found it.
Your review needs to establish whether the tool still matches what the team approved, who can access its data, and which answers require evidence from the supplier.
Some of those answers may be inconvenient. They are generally more useful while you still have choices. The dividend is a review that finds the difference while keep, adjust, pause, and retire are all still on the table.
Which AI tool in your business has changed since you approved it, and who would hear about it first?
The AI Debt Diagnostic offers 9 questions across all 9 debts, drift included, with results sent to your inbox.
Every edition of this series is at digitalbard.co/perspectives.