The admission hiding in plain sight
Backstage at a recent Los Angeles event, Google Cloud COO Francis de Souza said something that should have triggered more alarm than it did: “There’ll be a transition period, and then I think we get to this better place.” The sentence was delivered in what TechCrunch described as the calm, measured manner of a university professor. That framing did its work. The quote read as reassurance. It was the opposite.
De Souza runs cloud operations for one of the three dominant AI infrastructure providers on the planet. When he describes a “transition period” in AI security, he is not offering a soothing metaphor. He is confirming that Google itself is mid-problem. The vendor layer — the companies selling enterprises on AI transformation — has not solved the security challenges those enterprises are being asked to navigate right now.
Most coverage treated the statement as responsible messaging, a vendor acknowledging complexity and counseling patience. The more accurate read is structural: if Google Cloud is still working through its own transition, no enterprise customer is buying a finished product. They are buying into an active experiment.
The professorial calm is part of the problem. “A better place” is a destination. It is not a shipped feature, a certified framework, or a contractual guarantee. Enterprises building procurement decisions, deployment timelines, and board-level risk disclosures around the assumption that AI security is largely solved are operating on a fiction the vendors themselves have not endorsed — they have just packaged the uncertainty in language that doesn’t sound like a warning.
De Souza’s actual security advice — treat it as a platform concern, not a bolt-on, don’t leave it to individual employees — is sound. But the gap between that advice and the sales motion pushing enterprises toward rapid AI adoption is where the real exposure sits. Google is telling customers what to do while simultaneously demonstrating that doing it correctly remains an unsolved problem.
What ‘navigating in real time’ actually means for enterprises
When Google Cloud COO Francis de Souza says enterprises will pass through “a transition period” before reaching a better place on AI security, he offers no date, no milestone, and no measurable exit condition. That is not an oversight — it reflects the actual state of the field. Security teams inside enterprises are now being asked to calculate risk timelines against a threat model that neither their vendors nor the attackers targeting them have finished writing.
The practical consequence is a structural inversion of the normal vendor relationship. Enterprises purchasing AI security tools are not acquiring proven protection. They are funding the final stage of product development while simultaneously running production workloads on it. What the market calls a security purchase is, operationally, a beta test — one where the cost of failure lands entirely on the buyer.
Google itself has not exited this transition. De Souza’s framing — careful, credentialed, delivered in the measured tone of someone who knows exactly what he is and is not promising — makes clear that even the company building the infrastructure layer is navigating the same uncertainty it is selling tools to address. That is not a criticism of Google. It is a description of the environment every enterprise security leader now operates in.
The damage this does to standard risk management practice is direct. Risk quantification models require known threat parameters, defined control effectiveness, and some estimate of how both change over time. None of those inputs are stable in the current AI security landscape. Vendors are updating threat models in response to attacks that had not occurred when the product shipped. Enterprises absorbing those updates mid-deployment are not patching known vulnerabilities — they are discovering, retroactively, what the threat surface actually was.
Security leaders who present AI deployment timelines to boards as if conventional risk calculus applies are working from an assumption the evidence does not support. De Souza’s “better place” may come. The timeline for getting there belongs to no one.
The missing context: AI security is a moving target by design
AI security doesn’t behave like a conventional vulnerability with a fixed patch and a closed ticket. Every time a model gets updated, fine-tuned, or wired into a new data source, the attack surface shifts. Security teams aren’t chasing a finish line — they’re chasing a target that moves every time the underlying system improves.
Francis de Souza, COO of Google Cloud, framed the current moment as a “transition period” that leads enterprises toward “a better place.” That framing suggests a linear progression: discomfort now, stability later. The actual trajectory is more complicated. AI systems don’t reach a security plateau after a certain number of iterations. Capability improvements and new vulnerabilities arrive in the same update. The model version that handles more complex reasoning tasks or connects to a broader set of enterprise data is simultaneously a more powerful tool and a larger attack surface.
This is the part most coverage leaves out. When an AI system gets smarter, it doesn’t get safer by default. The same architectural changes that allow a model to process more context, execute more autonomous actions, or integrate with more external APIs also create new vectors that didn’t exist in the previous version. There is no static configuration to certify and lock down.
De Souza’s core prescription — that security must be built into the platform from the start rather than bolted on — is correct and necessary. But it doesn’t resolve the dynamic problem. Even a security-first deployment faces ongoing exposure as the model evolves post-launch. An enterprise that locks down its AI environment today will face a different threat landscape after the next model update, the next third-party integration, or the next fine-tuning cycle. Google, which employs some of the most sophisticated AI security researchers in the world, is still navigating this in real time. Enterprises with a fraction of those resources shouldn’t plan as if the problem has a defined end state.
Why this moment specifically demands a different enterprise posture
The pressure to ship AI faster than competitors is hitting enterprises at exactly the wrong moment — before the security foundation exists to support it. Francis de Souza, COO of Google Cloud, acknowledged this openly at a recent Los Angeles event, describing the current moment as “a transition period” before reaching what he called “a better place.” The problem: enterprises are deploying production systems right now, not in some future better place.
Security professionals have spent years fighting the “bolt it on later” instinct with every wave of emerging technology — cloud, mobile, IoT. AI is compressing that entire learning curve into months instead of years. The speed of enterprise AI adoption is outrunning the institutional knowledge needed to deploy it safely, and the normal feedback loops that eventually produced mature security practices for previous technologies haven’t had time to develop.
What makes this moment different is who enterprises are waiting on. With previous technology transitions, a vendor eventually shipped a patched, hardened, production-ready product and enterprises could upgrade into safety. That path is closed here. De Souza’s own message — that security “is not something you can bolt on later” — comes from a company that is itself mid-transition on AI security. Google is not delivering a solved problem and waiting for customers to catch up. Google is figuring it out in parallel with its customers.
That eliminates the most common enterprise coping strategy: delay deployment until the platform provider resolves the hard problems. No credible timeline exists for when AI security moves from active research problem to solved commodity. Enterprises waiting for that moment are making a business decision disguised as a security decision — and the competitive cost of waiting will push most of them to deploy anyway, without the posture to match.
The result is a direct collision between business velocity and security reality, with no external force positioned to resolve it.
What enterprises should actually do while everyone figures this out
Google Cloud COO Francis de Souza told enterprises to take a “platform approach” to AI security — treating it as foundational, not optional. That advice lands differently when you know Google itself is still working through its own security transition. Enterprises can’t afford to wait for vendors to finish figuring it out.
The first move is building internal AI security fluency. Security teams need to understand prompt injection, model poisoning, data exfiltration risks, and agentic AI failure modes — not rely on vendor documentation to explain what those threats even mean. When the company selling you the platform is still in a transition period, outsourcing all security judgment to that same vendor is a structural mistake.
The second move is abandoning the one-time security sign-off. Traditional IT security reviews treat deployment as an endpoint. AI deployments don’t work that way. Models get updated. Integrations expand. New attack surfaces appear after launch, not before it. Enterprises need continuous re-evaluation cycles — quarterly at minimum — with documented owners and explicit triggers for escalation. A deployment that was low-risk in January may not be low-risk in September.
The third move is getting specific with vendors. “Transition period” is not a security commitment. Enterprises should demand written, time-bound milestones: when will agent behavior be fully auditable, when will data residency guarantees apply to AI workloads, when will red-team results be published. Vendors who can’t answer those questions with dates are asking for open-ended trust they haven’t yet earned.
De Souza is right that the industry eventually gets to a better place. The problem is “eventually” doesn’t protect enterprise data today. The companies that come through this period intact won’t be the ones who waited for the ecosystem to mature — they’ll be the ones who built security competency in-house while everyone else was still waiting for a vendor to make the problem disappear.
The bigger picture: shared uncertainty is not shared responsibility
Google Cloud COO Francis de Souza deserves credit for saying publicly what many vendors only admit in private: AI security is unsolved, the transition period is real, and enterprises need to treat security as a platform-level commitment rather than a feature bolted on after deployment. That candor is rare at the executive level. It is also not the same as protection.
Acknowledgment does not transfer liability. When a board faces a breach, a regulator demands documentation, or a customer sues over exposed data, the fact that Google said “we’re all figuring this out together” provides zero legal cover and zero remediation. Enterprises hold the data. Enterprises sign the compliance agreements. Enterprises absorb the reputational damage. The vendor moves on to the next conference.
The “shared uncertainty” framing is the specific risk most coverage ignores. When the largest AI infrastructure providers describe an ongoing transition period in measured, professorial tones, they normalize a level of ambient risk that boards and regulators will not accept once something goes wrong. Regulators under GDPR, HIPAA, and emerging AI-specific frameworks in the EU do not grade on a curve because the technology was new. They assess whether organizations took reasonable precautions given what was knowable at the time. A Google executive confirming publicly that the challenge is real makes the “we didn’t know” defense harder to sustain, not easier.
The gap between vendor candor and vendor accountability is where enterprises will get hurt. De Souza’s advice — take a platform approach, build security in from the start — is correct. But Google issuing that guidance while simultaneously navigating the same unresolved problems means enterprises cannot treat vendor recommendations as a substitute for independent risk assessment. The responsible read of Google’s honesty is not reassurance. It is a signal that enterprises need to set their own security timelines, conduct their own threat modeling, and stop waiting for infrastructure providers to hand down a finished solution.