The 3 Ps: People, Process, Platform
The Data + AI Summit sessions on organizational readiness and AI culture had a consistent message: teams that are succeeding with AI aren't the ones with the most sophisticated technology. They're the ones that got the people, process, and platform working together. I've been saying some version of this for years about data engineering in general, but it's worth restating specifically for AI.
The three Ps aren't equal. And they're not in the right order when most teams approach AI adoption.
Most Teams Get the Order Wrong
The typical AI adoption sequence: buy or build a platform, prototype some use cases, then figure out process, then hope the people part works itself out. This is backwards. The order that actually works: start with people, build process, then select platform.
People first because the capability gap is a people gap, not a platform gap. The shortage isn't in AI platform features — it's in people who understand the domain well enough to identify high-value use cases, understand the data well enough to prepare good training examples, and understand production systems well enough to deploy and maintain them. Before you pick a platform, know what your people can actually do.
Process second because AI systems have failure modes that require different operational processes than traditional software. You need a model update process, an evaluation process, a human-in-the-loop escalation process, and a cost monitoring process before you deploy anything. These can't be retrofitted after the fact.
Platform last — not because the platform doesn't matter, but because the platform choice should be constrained by the first two. Pick the platform your people can operate, that supports your required processes, and that fits your governance requirements. In most cases, that's a shorter list than the one you start with.
What Orgs That Get This Right Look Like
The organizations I've seen that consistently deliver AI systems into production share several traits: they have explicit data ownership — named people accountable for specific data domains, whose job evaluation includes data quality. They have defined evaluation standards that apply to AI systems before production deployment. And they treat model monitoring as a first-class operational responsibility, not as something the data science team handles "when they have time."
The culture marker that predicts success better than any technical indicator: does the data engineering team have the organizational authority to reject a data source because it's not ready? In organizations where data quality is a negotiated political outcome rather than a technical gate, AI systems consistently underperform. The quality of the output is bounded by the quality of the input, and the quality of the input is determined by who has the authority to enforce standards.
A Framework for Building a Data + AI Culture
Three concrete things: give data engineers the explicit authority to block pipeline deployments on data quality grounds, same as security engineers can block deployments on security grounds. Define "done" for AI projects to include monitoring, evaluation, and fallback path — not just "model is deployed." And run quarterly reviews of production AI system performance, not as a blame exercise but as an organizational learning process. These aren't technology investments. They're cultural commitments. As always, I'm here to help.