Google Cloud's Francis de Souza puts AI security on the boardroom agenda

Francis de Souza, COO of Google Cloud, is making a point that sounds simple only until a company has to operationalize it: AI security cannot wait until the end of the project. According to The Decoder, de Souza argues that security has to be built into AI strategy from day one, because generative AI is no longer just a contained lab experiment.

That distinction matters. Traditional IT security has often been described through access, networks, patches, logs, and incidents. AI adds a harder layer of governance. A model can work with internal data, write text or code, generate recommendations, summarize documents, and influence decisions. The risk is not only who can enter the system. It is what the system is allowed to do, which data it may use, how its output is checked, and who is accountable when a confident answer becomes a bad business decision.

That is why the boardroom-versus-server-room framing is more than standard vendor language. If a company first places AI into sales, support, analytics, or software development and only later tries to add controls, it has already built operational dependency. At that point, every correction becomes slower, more expensive, and more politically difficult. Data boundaries, model access, audit trails, output checks, and risk escalation need to be designed before production use, not repaired after the first uncomfortable failure.

The NIST AI Risk Management Framework is a useful reference here because it does not reduce AI risk to a single security control. NIST frames it through mapping, measuring, managing, and governing systems. In practical terms, an organization needs to know where AI is used, which data it touches, which decisions it can affect, who may change settings, and how the system is stopped when it starts producing harm or wrong recommendations.

Google Cloud already has a broader catalog of AI products, but the core issue in this story is not the tooling list. It is sequencing. A tool deployed without clear data ownership, auditability, and an agreed escalation path is not merely a technical risk. It becomes a governance risk, because nobody can quickly explain what happened, why it happened, and who has the authority to pause the system.

Precision matters: the supplied source does not describe a new security incident, public dataset, benchmark, or technical breakthrough. Its value is the signal. When the COO of a major cloud provider says AI security belongs in the boardroom, the market conversation shifts from whether AI can be deployed to who governs it once it becomes part of real operations.

For companies now accelerating AI projects, the expensive mistake would be treating security as the last phase before production. Day one should define permitted data, accountable owners, human review thresholds, decision logging, and the escalation process. Anything added later is usually added against habits that are already in place.