The pressure to put AI in more hands is pressing, as is the pressure to keep it safe. Reconciling those two forces was the throughline of a recent roundtable that brought together senior technology leaders from healthcare, financial services, industrial automation, and enterprise software.

What emerged was less a debate about which models to use and more a candid conversation about the organizational, architectural, and security work that determines whether AI succeeds at scale.

A few themes stood out from the conversation.

AI failures are rarely about the models

The leaders in the room kept returning to a shared observation: when AI initiatives break down, the model is almost never the culprit. The failure points are data handling, unclear ownership, and architecture.

One story captured the ownership problem better than any framework could. A principal engineer, unsure whether they had the authority to move forward, handed a decision to the product team, where a Junior Product Manager fresh out of college inherited it. Feeling forced to produce an answer, the Product Manager made a rushed call. From there, organizational boundaries hardened. 

As one panelist described it, "the funniest thing I've seen organizations trip over is when a principal software engineer thinks that they need permission to do something, so they throw it over the wall to the product management team, and there is a very junior Product Manager right out of college who picks up the ball and now they're shaking in their boots." 

The developer wanted the work shipped, the Product Manager had to defend a hasty decision, and legal eventually stepped in to protect the enterprise. Progress stalled entirely.

Ultimately, the lesson was about designing ownership so this scenario never arises.

Safe accountability, built into the architecture

That idea has a name the group kept using: safe accountability. It moves past the reflex of naming someone responsible after something goes wrong. Instead, it means designing accountability directly into the enterprise architecture and the solutions themselves.

As one participant put it, "you're not just assigning a role to someone. You're designing that into the architecture—into the design of the overall enterprise solutions that you're creating."

In practice, that means telling people exactly what they own and what is expected of them, clearly enough that they feel confident raising their hand when something looks wrong. Rather than a sign of failure, early flags are a feature of a healthy system. When owners feel safe to surface problems, the whole organization builds and innovates with more confidence.

This requires collaboration across legal, technical, and business teams from the start, along with visibility into how solutions evolve after deployment. The alternative is the stalled project above, discovered too late.

Decision-first architecture and vertical value streams

If accountability is the cultural half of the answer, architecture is the structural half. Several leaders advocated for what they called decision-first architecture. Meaning, aligning delivery and data strategy around the specific decisions the enterprise needs to make, rather than around horizontal silos.

Most organizations still separate teams by layer, with UI, data, models, and governance each sitting in its own function. Decision-first architecture scales vertically instead, mapping directly to business capabilities and decision outcomes. The related concept, vertical value streams, aligns those horizontal stakeholders around a single vertical outcome.

The payoff is speed and clarity. When capabilities are organized around outcomes, teams pivot faster, communicate more effectively, and deliver. When they rely on traditional horizontal shared services, one leader noted, their ability to do all three diminishes sharply.

There was also a note of realism. "Organizations are foundationally not designed to actually do the kind of things that everybody was talking about at scale," one participant acknowledged. Recognizing that gap is the first step to closing it.

Design thinking as a defense against AI slop

A recurring failure mode drew knowing nods around the table was the pressure to use AI for its own sake. One speaker recalled a team whose entire project scope amounted to wanting to "build something with AI" to show management they were keeping up, with no real use case behind it. The fix was a design thinking session to define the actual problem, success metrics, and stakeholders. That single session grew into seven, and the result was a properly scoped project with far less long-term technical debt.

The same pressure produces poor architectural choices. One participant described teams taking a perfectly functional, cost-effective robotic process automation workflow and refactoring it into an AI process that did the same job while driving up token costs. The technology was newer. The outcome was worse.

Underneath these examples sits a phenomenon the group called AI slop, i.e. professional-looking output with no real meaning behind it. Picture a dashboard full of polished charts whose numbers were never vetted. It looks authoritative and communicates nothing true.

The scale of the noise is striking. One leader's organization audited the automated use case ideas its staff submitted, most of them driven by the urge to showcase AI. Out of hundreds of ideas, only five delivered real business value. That gap is why the group insisted on keeping humans in the loop to validate outputs and on treating design thinking as a filter that separates genuine problems from the appearance of progress.

Security as a first principle, not an afterthought

For leaders in regulated industries like healthcare and finance, security sits at the top of the board's agenda. The techniques the group described were concrete, including sandboxing untrusted code, automated guardrails, and robust metadata catalogs.

The harder point was cultural. Security and speed pull against each other, and the group was clear that security has to be a core requirement from the first design decision versus a gate bolted on at the end. Retrofitting safety is slower and weaker than building it in.

The threat landscape adds urgency. Malicious actors have the same advanced models everyone else does, which means organizations increasingly need to use those models to red-team their own perimeters. As one participant warned, "unless you're using the absolute newest technology, you don't know if your existing stack is safe."

The common thread

Across accountability, architecture, design, and security, the principle that held was that control and democratization are more similar than they seem. The organizations getting this right treat governance as the thing that makes broad AI access possible, designing ownership, structure, and security into their solutions from the beginning rather than negotiating them afterward.

That is the harder path. It is also the one that turns AI from a collection of impressive demos into durable enterprise value.