AI Risk Factor Disclosure in SEC Filings 2026: Item 105, MD&A and the Boilerplate Problem

Six Patterns That Turn a Filing Into an Exhibit

Each of these appears in filings routinely. For each: the shape it takes, and why it creates exposure rather than reducing it.

The hypothetical that already happened

How it reads: "Our AI models may produce inaccurate outputs, which could harm our reputation" — filed by a company that had already had a customer-facing incident, already issued credits, and already lost the account.
Why it hurts: Framing a materialised risk in conditional language is the single most reliably actionable disclosure defect. It is not a failure to disclose a risk; it is an affirmative statement that the thing might happen, made by someone who knew it had. Courts treat that as a misleading statement rather than an omission, which changes the pleading standard in the plaintiff's favour.

The capability claim with no defined term

How it reads: "Our platform is powered by proprietary artificial intelligence." Elsewhere, the technology is a vendor API with a rules layer on top.
Why it hurts: Proprietary and powered-by are the two words that draw enforcement attention, because they are checkable. The question an examiner asks is simple and unforgiving: what did you build, what did you license, and does the filing let a reader tell the difference. A material overstatement of your own technology's role is the core of the AI-washing theory.

The metric with no denominator

How it reads: "AI-driven revenue grew 300% year over year" with no definition of AI-driven and no base disclosed.
Why it hurts: Non-GAAP and operating metrics need consistent definitions and a stated basis of calculation. An AI-attributed metric whose definition drifts between quarters, or that includes revenue from products with an incidental AI feature, is a presentation problem that becomes a restatement problem when someone reconstructs it.

Risk factors that could belong to anyone

How it reads: Three pages on AI regulation, competition and reputational risk that would be equally true of every company in the index.
Why it hurts: Item 105 asks for the material factors that make an investment in this registrant speculative or risky, and expressly discourages risks that could apply generically. Generic AI risk factors fail on their own terms and, worse, consume the space where the registrant-specific risk — vendor concentration, a single model dependency, one contract with a termination-for-accuracy clause — should have been described.

Silence on concentration

How it reads: Heavy dependence on one model provider, one cloud, or one data licence, disclosed nowhere.
Why it hurts: Supplier concentration and dependence on a single arrangement is conventional disclosure territory that AI has quietly recreated at scale. Pricing changes, deprecation of a model version, or a licence dispute upstream can each impair the product, and a reader cannot assess that from a filing that never names the dependency.

The oral statement the filing does not support

How it reads: Prepared remarks describing AI as transforming the business, against a filing that discloses a pilot.
Why it hurts: Earnings calls, conference appearances and investor decks are all attributable statements. The gap between the enthusiasm on the call and the caution in the filing is the first thing a plaintiff's firm charts, and the safe-harbour protections that cover forward-looking statements do not reach statements of present fact about what your product does today.

Six Buckets a Registrant-Specific AI Section Should Cover

Item 105 wants what makes an investment in you risky. These are the questions that produce that content; the answers are necessarily uncomfortable, which is the point.

Bucket	The question that generates real disclosure
Dependence and concentration	Which single third parties can degrade your product, and what happens contractually if they change price, terms, availability or model behaviour? Name them where material.
Legal and regulatory exposure specific to you	Which regimes actually reach your use case — sector regulators, state AI statutes, foreign frameworks — and what would compliance cost or restrict? A list of every AI law in existence is not a risk factor.
Intellectual property in both directions	Training-data provenance and the claims that could follow it, ownership of outputs your customers rely on, indemnities you have given, and indemnities you depend on receiving from upstream vendors.
Performance and incident history	Has a model failure already caused customer harm, refunds, churn or litigation? If so, the risk factor must be written in the past tense, and MD&A should carry the financial consequence.
Capital intensity and unit economics	Inference cost per unit of revenue, compute commitments, and how gross margin behaves as usage scales. This is MD&A material more than risk-factor material, and it is where analysts find the discrepancies.
Controls over the claims themselves	Who verifies that a product marketing claim about AI is accurate before it reaches a filing, a deck or a call? Disclosure controls and procedures have to cover this, and in most companies nobody owns it.

The tense audit

Take every AI sentence in your last filing that contains "may", "could" or "might". For each one, ask a product engineer a single question: has this already happened, even once, even in a form we resolved quietly?

Every "yes" is a sentence in the wrong tense, and every sentence in the wrong tense is a misstatement rather than an omission. This audit takes an afternoon, requires no counsel to perform, and finds the exact defect that carries the most exposure.

Frequently Asked Questions

Why is a generic AI risk factor worse than a short one?

Because it creates length without protection and it crowds out the disclosure that would have worked. Item 105 calls for a discussion of the material factors that make an investment in the registrant speculative or risky, organised under meaningful headings, and it explicitly steers filers away from risks that could apply generically to any issuer — a summary is required where the section runs long, which is itself a signal about what regulators think of sprawling risk sections. A three-page recitation of general AI risks does not insulate you from a claim about the specific thing that went wrong, because disclosure is assessed against what a reasonable investor would have wanted to know about this company, not against volume. It also creates a second problem: when the specific risk does materialise, the plaintiff's narrative writes itself as a comparison. Here is the page of generic warnings you published, and here is the concrete dependency you knew about and did not name. Specific, shorter and unflattering beats comprehensive and generic, on every measure that matters.

What is AI washing in a securities context, as opposed to a marketing one?

It is materially overstating the extent, sophistication or role of artificial intelligence in your business to investors, and the enforcement theory does not require the technology to be fake. Cases in this area typically feature a real product with a real model somewhere in it, described to investors in terms that imply far more — proprietary where the model is licensed, deployed where it is piloted, driving results where it is a feature, autonomous where a human does the work. The reason it is attractive to enforcement staff is that it is unusually verifiable: engineering documentation, vendor invoices, internal roadmaps and support tickets all exist, and they either support the description or they do not. Two practical defences, both boring. Maintain a substantiation file for every AI claim that appears in an investor-facing document, mapping the claim to the artefact that supports it. And insist that claims be written by someone who could be deposed about how the system works, rather than by someone describing what it is meant to become.

Does the forward-looking statements safe harbour cover our AI claims?

It covers projections and plans; it does not cover statements of present fact, and most problematic AI statements are the latter wearing the former's clothing. "We expect AI features to contribute meaningfully to revenue next year" is forward-looking. "Our platform uses proprietary AI to automatically resolve customer issues" is a claim about what exists today, and no amount of cautionary language converts it. Two further limits catch filers out. The protection generally depends on meaningful cautionary language that identifies the specific important factors that could cause actual results to differ — recycled boilerplate that does not match the projection has been held not to qualify. And the safe harbour does not extend to statements made with actual knowledge of falsity, which is precisely the allegation in an AI-washing case, so the protection tends to evaporate at the moment it would matter. The practical drafting rule is to separate the two categories physically: describe capabilities in the present tense only to the extent you can substantiate them, and keep the aspiration clearly labelled and specifically hedged.

When does an AI incident become material enough to disclose?

When there is a substantial likelihood that a reasonable investor would consider it important — which, for AI incidents, is usually driven by financial and contractual consequence rather than by technical severity. A model defect that produced no customer harm and no financial effect is generally not material. The same defect becomes material when it triggers customer credits, contract terminations, a regulatory inquiry, a remediation programme with meaningful cost, or a pattern that undermines a capability claim you have already made to investors. That last one is the trap: an incident that is small in dollars can be material because it contradicts a public statement, and the disclosure obligation then attaches to the correction of the earlier statement rather than to the event. Note also the interaction with cybersecurity disclosure. Where the incident involves unauthorised access, exfiltration of a model or training data, or compromise of a system through an AI interface, the incident-reporting regime has its own determination-without-unreasonable-delay standard and its own timeline, and the assessment is required to run in parallel rather than after your internal investigation concludes.

How should MD&A treat AI spending?

As a discussion of how the money changes the numbers, not as a technology narrative. The useful content is specific and largely unloved: what compute and model costs are running at, how they are classified between cost of revenue and operating expense, whether the classification changed and why, what commitments you have entered into and over what term, and how gross margin behaves as usage grows. A software business whose marginal cost per customer used to be near zero and is now materially variable has undergone a change in its economics, and describing that plainly is the most valuable AI disclosure most companies could write. Two known trouble spots. Capitalisation policy for AI development costs is judgemental and inconsistently applied across peers, so the policy and any change to it should be visible rather than inferred. And multi-year compute commitments create obligations that need to appear where obligations appear — a filing that celebrates AI capacity in the business section while the commitment is invisible in the financial discussion has told the story in the wrong order.

We are private and planning an IPO. Does any of this apply yet?

Every statement you make now is a draft of a statement you will have to stand behind later, and the diligence process will surface the gap. Registration statements carry a strict liability regime for material misstatements in the registration statement itself, with a due-diligence defence available to others in the chain — which is why underwriters' counsel will interrogate AI claims harder than anything else in the technology section. Expect the substantiation exercise to be uncomfortable if nobody has been maintaining it: marketing pages, sales decks, funding announcements and press quotes from the last three years will be assembled and compared against what the product does, and inconsistencies get resolved by rewriting the description downward at the least convenient moment. The cheap version of this work is to start the substantiation file now, while claims are being made rather than years afterwards, and to align the language in customer-facing and investor-facing materials so that the pre-IPO cleanup is an edit rather than a retraction. The companies that struggle here are not the ones with weak technology; they are the ones whose descriptions were written by people who never had to prove them.

Who inside the company should own AI disclosure?

Someone with authority over both the engineering reality and the published language, which in practice means the disclosure committee needs a technical member and a defined intake from product. The structural failure is ordinary: marketing writes capability claims, investor relations reuses them, the filing inherits them, and no one in that chain could describe the system's actual architecture under questioning. Disclosure controls and procedures are required to be designed to ensure that information required to be disclosed is recorded, processed, summarised and reported within the required timeframes and accumulated and communicated to management — and information about what your AI actually does is squarely inside that. Three concrete mechanisms work. A standing agenda item where product engineering confirms or corrects the capability language before it is filed or spoken. A substantiation register that any claim must reference before publication. And a rule that any statement about autonomy, accuracy or proprietary technology requires a named technical owner. None of this is expensive. It is unglamorous, and it is the difference between an incident being a bad quarter and an incident being an enforcement matter.

The Most Dangerous Sentence in Your Filing Starts With "Our AI Models May"