Why Alex Karp isn’t wrong, and why AEC leaders should care

A timely breakfast with an ENR 500 CEO

It may have been 4th of July morning, but a friend of mine, the CEO of an ENR 500 company, decided to have breakfast anyway. The topic: Alex Karp’s rant on CNBC. If you think he’s a wild man, you’re correct. If you weren’t actually paying attention, you missed the point.

Karp’s real argument, once you strip out the theatrics, is about who controls the data once you’ve handed it over. He’s talking about enterprise software generally. But nobody in that CNBC studio was thinking about what happens on a jobsite, where the data problem is actually harder than anything Karp described.

Here’s why. A project isn’t one company deciding whether to trust one AI vendor. A project is an owner, a GC, a dozen subs, an architect, an engineer of record, sometimes a manufacturer or two, all contributing information into something that has to function as a single, coherent record. Shared project data only works if everyone contributes to it. But contribution isn’t the same as surrender.

Every entity on a project has two kinds of information. There’s project data: the drawings, the RFIs, the schedule, the field conditions, the closeout documents. That belongs to the project and needs to flow freely so the project can succeed. And there’s enterprise data: pricing methodology, internal margins, proprietary means and methods, the sub’s competitive advantage, the GC’s internal communications about strategy. That belongs to the company, not the project, and it should never cross into a shared pool just because everyone’s using the same platform.

Most software doesn’t draw that line. It either locks everything down so tight that collaboration is painful, or it opens everything up so wide that a sub is one API integration away from exposing the pricing logic that keeps them in business. Neither is acceptable. What a real shared data model needs is control over what gets contributed, by whom, and an audit trail of how it’s used afterward. Not “trust the platform.” Control what goes in, and see what happens to it once it’s there. That’s not a technology preference. That’s the only way you get a sub, an architect, and an owner to all put real information into the same system without one of them getting burned.

Now here’s the part that made my friend put his coffee down. Every AI tool being deployed on a project right now belongs to one entity. The GC has one. The owner might have one. A sub might be running their own. Each of those tools is only as smart as the data the entity using it can see. Which means each tool is optimizing for that one entity’s success on the project. Not the project’s success.

That sounds like a small distinction. It isn’t. An AI tool built for a GC will get very good at protecting the GC’s schedule, the GC’s margin, the GC’s exposure. That’s exactly what it should do, if that’s who it works for. But no single entity’s AI, no matter how good, has the full context of the project. It doesn’t see what the architect knows about a design intent that hasn’t been documented yet. It doesn’t see what the sub knows about a material lead time that’s about to blow up the sequence. It sees its own slice, and it optimizes for its own slice. You end up with five entities on the same project, each getting smarter and more efficient at defending their own position, while the thing they’re all supposedly building together gets none of that intelligence applied to it.

Karp’s version of this problem is about a company competing against the vendor that’s supposed to be serving it. Ours is stranger. It’s five or six companies, all supposedly on the same team, each getting a private AI advantage that has nothing to do with whether the project itself succeeds. You can have a project fully “AI-enabled” in that sense and still watch it go over budget and past schedule, because every tool on it was built to make its owner look good, not to make the building come out right.

This is the argument for shared project intelligence that actually deserves the name. Not a data lake everyone dumps into and hopes for the best. A structure where each party controls what it contributes, where every use of that data is auditable, and where the intelligence layer sitting on top of it is actually accountable to the project, not to whichever entity happened to buy the license first.

My friend and I didn’t agree on much about Karp’s delivery that morning. But we agreed on this: the project is the thing that needs to succeed. Not the GC. Not the owner. Not the sub. The project. And right now, almost nothing being sold as AI in this industry is built with that as the actual client.

That’s the point everyone half-watching Karp on the Fourth of July missed. He was yelling about enterprises losing control of their own data. We’ve got the same problem, plus one nobody’s built for yet: intelligence that’s loyal to a company instead of loyal to the thing that company is supposed to be building.

Here is a checklist of questions that every AEC CEO should ask their IT Department.