Dear CIO,

You hear it everywhere: “AI is producing slop.” The conversation usually revolves around bad code, lazy writing, shallow design, and generic content. However, framing AI slop as a delivery artifact misses the deeper issue. AI slop is not really about code. It is about what happens when organizations adopt artificial intelligence faster than they develop judgment, trust, accountability, and control. We must define AI slop as something more damaging than low-quality output. It includes code that technically works, but nobody understands, and documents that sound polished but say nothing. It manifests as decisions made faster than they can be reviewed, workflows that feel productive while quietly creating risk, and teams shipping more while learning less. AI slop is not just bad artifacts; it is organizational scar tissue.

Best Regards,
John, Your Enterprise AI Advisor

The Erosion of Accountability, Ownership, and Trust

Beneath this residue is a dark layer no one seems to be discussing: the anxiety. AI introduces fear of being replaced, of falling behind, of not using AI “enough,” and the paradox of being judged for using it or not. This fear changes behavior. People might stop asking good questions. They might hide uncertainty. They overstate confidence. They produce more, but think less. Slop grows when people use AI defensively instead of deliberately. This dynamic is worsened by the dissolution of efficacy and the illusion of efficacy.  

Christina Maslach’s work on burnout, especially the Maslach Burnout Inventory, is useful here because burnout is not only about exhaustion. It also includes cynicism and reduced professional efficacy: the feeling that one’s work no longer produces meaningful, competent, or valuable results. In an AI-saturated workplace, efficacy can become a silent killer. People may appear more productive while privately feeling less capable, less necessary, and less connected to the quality of their own judgment. AI makes people feel effective because it reduces friction. A draft appears instantly, a function compiles, a summary looks coherent, but speed can disguise weak reasoning. There is a vast difference between generating output and actually solving a problem, understanding the tradeoffs, and owning the result. AI can increase productivity while decreasing efficacy if teams confuse “done faster” with “done better.” Over time, that gap matters. When people no longer trust their own contribution, or cannot tell whether their work is genuinely good or merely AI-assisted and acceptable-looking, they do not just burn out from doing too much. They burn out from feeling increasingly irrelevant to the outcome.

Ironically, AI is often sold as a cure for burnout, yet in practice, it can become a burnout amplifier. More output creates a heavier review burden. Faster work resets expectations. People are expected to supervise machines while continuing to do their old jobs, and teams are asked to “do more with less.” AI does not automatically reduce work; it changes the shape of work into constant verification, prompting, editing, and risk management. Burnout comes when humans become the cleanup crew for machine-generated abundance. As this abundance floods the system, a quiet organizational crisis unfolds: the loss of control. AI changes who feels in control. Developers may no longer understand every line of the codebase. Managers may no longer know how work was produced. Legal departments may not know what data entered the system, and security teams may not know where sensitive information went. This loss of control appears in subtle, everyday statements: “I don’t know why the model suggested that,” or “The output looked right,” or “We didn’t realize that data was included.” Nobody owns the decision because “the vendor handles it.” AI slop accumulates wherever control is delegated without accountability. This delegation without accountability turns AI slop into a security issue. The risks extend beyond traditional code vulnerabilities to include sensitive data pasted into tools, prompt injection, over-permissioned agents, generated code with hidden flaws, unsanctioned tools, and model outputs treated as trusted instructions. Security teams are no longer just protecting systems; they are protecting judgment, context, and workflow integrity. AI slop becomes a security issue when organizations cannot trace what was shared, generated, trusted, or deployed.

Alongside risk and security comes the fog of ownership and intellectual property. AI makes authorship blurry. Who owns the output? Who has the right to reuse, modify, commercialize, or ship it? What was the model trained on? Did an employee paste proprietary material into a third-party tool? Is the generated code contaminated by licensed material? These concerns are not abstract edge cases; they affect product strategy, brand voice, code ownership, customer deliverables, and competitive advantage.

For authors, this is not theoretical. As one of the authors of The DevOps Handbook, I am now watching this ambiguity play out in real time through the litigation and proposed settlement involving Anthropic. The issue is not only whether a book was copied, scraped, downloaded, or used in training. It is what happens after the book has already been absorbed into a model. If the model can answer questions, summarize practices, reproduce concepts, or influence outputs in ways that indirectly draw from the work, then the harm is not limited to a single act of ingestion. The work may continue to live inside the system as a capability, a pattern, and commercial value.

That is why a settlement that feels like pennies on the dollar raises a deeper question than compensation. Am I simply settling a past claim, or am I functionally giving up my ability to contest the downstream value Anthropic may have already extracted from the book? I may not be giving up ownership of The DevOps Handbook itself. But if a settlement releases claims tied to Anthropic’s past use of the work, then I may be giving up the right to challenge how that past use helped create a model that continues to answer, generate, and compete in the domain my coauthors and I helped define. That distinction matters. Ownership on paper is not the same as control in practice.

The deeper problem is that AI-generated work can feel ownerless, while human-created work can be treated as raw material. A person may prompt it, a model may generate it, a company may deploy it, and a customer may rely on it, but accountability can become diffused across all of them. That diffusion is dangerous. Work without clear ownership is harder to defend, audit, license, and improve. If no one can say where an artifact came from, what inputs shaped it, what rights attach to it, or who is responsible for its use, then the organization has not created leverage. It has created liability.

AI slop includes work that looks usable but carries unclear ownership. It is not enough for generated content or code to be plausible, polished, or functional. Teams need provenance, review, rights management, and a named human or function accountable for the final artifact. Otherwise, AI does not just blur authorship; it erodes the chain of custody that makes work trustworthy. Furthermore, accountability does not disappear just because an AI is involved. AI can generate, recommend, summarize, classify, prioritize, and decide, but legal responsibility remains squarely with the organization. Potential legal exposure includes inaccurate advice, discriminatory decisions, privacy violations, contract breaches, regulatory noncompliance, and misrepresentation to customers or employees. The danger is not simply that AI makes mistakes. The danger is that AI makes mistakes at scale, with confidence, inside systems people assume are neutral. AI does not absorb liability; it redistributes it, often invisibly. Air Canada learned this the hard way when its chatbot gave a customer incorrect information about bereavement fares, and the company was still held responsible for the information its system provided. The lesson was simple but important: a chatbot is not a separate moral, legal, or operational actor. It is part of the company’s service surface.

So why did code become the scapegoat for all of this? Code is easy to inspect, blame, and measure. Bad code has obvious symptoms: bugs, outages, and security flaws. But the deeper problems are cultural and operational. Who reviewed the work? Who understood the risks? Who decided AI was appropriate in the first place? Who owns the outcome? What process changed? What incentives encouraged speed over judgment? Code is simply where AI slop becomes visible, not where it begins. The real problem organizations are facing is judgment debt. Just as technical debt accumulates when teams ship shortcuts, judgment debt accumulates when teams accept AI output without building the muscles to evaluate it. Judgment debt shows up as less expertise over time, more dependence on tools, a weaker review culture, and an increase in plausible nonsense. It means fewer people can explain the work, widening the gap between production and comprehension. AI slop is what judgment debt looks like at scale. What does better AI adoption look like? It means establishing clear rules for where AI can and cannot be used. It requires human ownership of final outputs and risk-based review standards. Security and legal teams must be involved early. AI-assisted work must be documented. Most importantly, we must train people to critique AI, not just prompt it, and we must measure outcomes, not volume. The goal is not to reject AI. The goal is to use it without surrendering judgment. Ultimately, AI slop is a leadership problem. It is not about code because code is only one artifact of a larger system. The real question is whether an organization can adopt AI without losing clarity, accountability, security, ownership, and trust. The future will not belong to the teams that generate the most. It will belong to the teams that still know what they are doing.