Why Is Enterprise AI Slower Than Startup AI, and When Is That Justified?
A stalled AI project looks identical whether the cause is a real risk or a process nobody questions. The fixes have nothing in common.
Why Is Enterprise AI Slower Than Startup AI, and When Is That Justified?
A stalled AI project looks identical whether the cause is a real risk or a process nobody questions. The fixes have nothing in common.
Paul Graham defines a startup as a company designed to grow fast [1]. Speed is the whole point, so it’s no surprise that startups ship quickly. Large companies are built differently, and Jeff Bezos described the usual failure in his 2015 letter to Amazon shareholders: “larger organizations tend to push most decisions through the heavy process meant for decisions you can’t undo, and the result is slowness and less experimentation” [2]. He came back to it in his 2016 letter, which treats slow decisions as a sign a company has slipped from “Day 1” to “Day 2” [3], and Andy Jassy was still addressing bureaucracy as a drag on speed in his 2024 letter [4].
I’ve seen the contrast from both sides. Early in my career I worked at a smaller IT company, and since then I’ve worked at two very large ones. The smaller company moved faster, and the people weren’t the reason. Fewer systems depended on any one change, the person who could approve something was a message away, and a mistake was cheap to reverse. The large companies are slower for the opposite reasons: more systems, more teams depending on any one change, and more at stake when something goes wrong. Some of that slowness buys real protection and some of it doesn’t, and telling the two apart is the hard part. That question is what this article is about, and it applies to AI projects the same way. I’m not naming employers or describing internal systems.
Two problems that look the same
Most online commentary puts the startup-versus-enterprise speed gap down to culture. Big companies are risk-averse, committees kill good ideas, nobody wants to be the person who approved the thing that went wrong. Some of that is true. But it merges two different problems.
The first is structural friction. Data access controls exist because the data is sensitive. A vendor contract creates a dependency you’ll live with for years. A new system has to coexist with authentication layers, pipelines, and downstream consumers you don’t get to redesign. This isn’t specific to AI. It’s the reason a new ETL job in a large organization needs a change request and a rollback plan while a solo analyst just runs the script.
The second is inertia: steps that exist because they’ve always existed, approvals routed to people who no longer have the context to judge them, review cycles that repeat because nobody owns the decision to stop. That friction costs time and buys no safety.
From the outside, both are the same event. A model that worked in the demo hasn’t shipped three months later. The fixes are different, though, and a wrong diagnosis means you either cut a corner that mattered or put up with a delay that didn’t.
What the reviewers are asking
“Bureaucracy” is a bad word for a review, because it hides the question the review is trying to answer.
A data access review asks what the agent sees that it doesn’t need, and, if its output lands somewhere it shouldn’t, how far the damage reaches. It’s the question you’d ask before adding a new consumer to a shared table.
A security review starts from the fact that an agent that reads internal documents or calls internal APIs is a new kind of integration point, and it fails differently from a normal service. Take prompt injection: instructions hidden in content the model reads, like a web page or a retrieved document, get followed as if the operator had written them. The Open Worldwide Application Security Project (OWASP), a nonprofit that publishes security guidance, ranks it first on its Top 10 for LLM applications [5]. SQL injection has a structural fix, parameterized queries, which keep code and data in separate channels. An LLM reads instructions and data as the same thing, text, so there’s no equivalent separation, and I’m not aware of a complete fix. The US standards agency NIST also lists it, in its 2024 generative AI profile, as an information security risk and recommends red-teaming for it, but that guidance is voluntary [6]. A security reviewer who says “we don’t have a standard answer yet” is describing where the field is.
Get Anastasiia Bakhtoiarova’s stories in your inbox
Join Medium for free to get updates from this writer.
A compliance review asks whether we can explain this decision later to an auditor, or to a customer who disputes the outcome. An audit trail is much easier to design in than to reconstruct afterward.
A test for telling them apart
I don’t have a clean metric, and I’d be skeptical of anyone who says they do. One test has held up for me: ask the reviewer to name the specific risk.
Justified friction has an owner who can answer, and the depth of review follows what the system touches. A chatbot answering public FAQ content gets a lighter review than one that reads customer account data, because the review is tracking something real. Inertia is uniform. Every request goes through the same process because nobody is evaluating the individual case.
A data access review that takes two weeks because someone reads the request and works out the blast radius is the process doing its job. A review that takes two months because it sits in a queue behind twelve others, and no one is allowed to reprioritize it, is just a queue.
The fixes split the same way. If the friction is structural, make the review better and faster. Build tooling for data classification, write standard patterns for common agent types so each new one doesn’t start from zero, and give security teams hands-on time with actual LLM failure modes so they aren’t reasoning by analogy to older threats. If the friction is inertia, the fix is organizational. Someone has to own the decision to simplify or drop a step, and that’s a harder conversation than any engineering work.
What I haven’t figured out
I can’t tell in advance which kind of friction I’m facing. What I can say from working in large companies is that process slows things down, and that process isn’t fixed. People change it. Someone asks why a step exists, finds it protects against nothing, and removes it. Two teams find out they’re running the same review on the same data and merge them. A request that used to go through a queue and several sign-offs gets a standard pattern, and the next one takes a day. None of that needed new technology. It needed someone who owned the step and was willing to question it.
The question I use to sort them is still “what data, what blast radius, what audit requirement.” After the fact, structural friction has answers and inertia produces silence. But I’ve only seen this from inside a narrow slice of organizations, and I’d expect it to look different where a wrong answer costs less than it does in mine.
Note: I used AI to help with proofreading — the examples, experience and opinions are mine.
References
[1] Graham, P. “Startup = Growth.” September 2012. https://paulgraham.com/growth.html
[2] Bezos, J. 2015 Letter to Shareholders (Type 1 and Type 2 decisions), Amazon.com, filed as Exhibit 99.1. https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm
[3] Bezos, J. 2016 Letter to Shareholders (“Day 2” letter, high-velocity decision making), Amazon.com, April 2017. Reprinted at https://www.entrepreneur.com/article/292797
[4] Fortune. Coverage of Andy Jassy’s 2024 Letter to Shareholders (bureaucracy and speed), April 10, 2025. https://fortune.com/2025/04/10/amazon-andy-jassy-learning-leaders-culture-bureacracy
[5] OWASP. “Top 10 for Large Language Model Applications,” LLM01: Prompt Injection. https://genai.owasp.org/llm-top-10/
[6] NIST. “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” (NIST AI 600–1), July 2024. https://doi.org/10.6028/NIST.AI.600-1
