Twelve questions to settle before funding an AI project in a mid-sized company

Transparency note. This article follows IgnitionAI's editorial policy. It relies on the European Commission's official pages on the AI regulation and on the NIST risk management framework, consulted on 5 November 2026. IgnitionAI publishes a RAG product, IgnitionRAG. This grid applies to it as to any other vendor; the article compares no solution and contains no statistic or cost estimate. The only figures quoted are dates taken from official texts. See Methodology and sources.

In a mid-sized company, an AI project is not decided at the prototype. It is decided when a committee commits a budget, a team and a calendar. At that point nobody votes on an architecture. The vote is on a decision that must improve, a corpus someone answers for, an error whose cost is known, evidence the committee will demand, and an exit if the result does not come. The twelve questions below are not technical: they are the ones an executive committee can ask without being specialist, and that a serious vendor answers without dodging. They are grouped in four stages — decide, prove, operate, exit — because a project with answers only in the first two is expensive in the last two.

Teams that first need to document the technical side — document scope, access rights before indexing, evaluation, operating conditions — will find that grid in Framing an enterprise RAG project: seven decisions to document before the prototype. This article addresses those who sign, not those who build: the two read in that order.

Decide: what the committee is actually committing

1. Which decision gets better, and for whom? A useful AI project improves an identifiable decision: granting credit, ruling on a clause, answering a customer, choosing a supplier, triaging a file. If the answer is "teams will save time", the committee is funding an impression, not a change. A good answer fits in one sentence and names the person whose work changes, plus the volume at stake. A better answer names the decision that is not made today for lack of accessible information.

2. Who owns the corpus, and who answers for its quality? A system that answers from documents inherits their defects: stale versions, duplicates, procedures written but no longer applied, missing annexes. So the question is not "do we have documents?" but "who owns this corpus, who decides which version is the right one, and who removes it when it no longer is". Without a name and a process, system quality decays from the first update, and nobody notices before the first wrong answer given to a customer.

3. What happens when the system is wrong? It will be wrong. The useful question is the cost of the error and how it is caught: a wrong answer inside an internal knowledge base is corrected; the same answer read by a customer, sent in a letter, or used to grant credit is not. A good answer states where a human validates, what happens when the source does not contain the answer, and how an error travels back to the team that can fix it. If the answer is "the system does not make mistakes", the committee is looking at a promise, not an evaluation.

Prove: what to demand before believing

4. On which question set do we measure? You do not measure an answering system with a demo. You measure it on a set of questions frozen before the project, with expected answers and the documents that carry them, including questions whose answer is "the corpus does not say". That set is built with the business teams, kept, and replayed on every change: it is the only object that lets you say, six months later, whether the system improved or degraded.

5. What evidence will the vendor replay in front of you? A demo is a sample chosen by the person showing it. The useful evidence is colder: the question set above, replayed on your documents, with citations displayed and the log of retrieved passages. Also ask what happens when a document is removed: the system must stop relying on it. A vendor who refuses to replay a test on your corpus, or cannot show which passages grounded an answer, is describing a product it cannot prove.

6. Who is allowed to see what, and how is that verified? In a mid-sized group, one tool often serves several entities, customers or clearance levels. The question is not only "do you handle permissions?" but "can you demonstrate that a query from one perimeter never returns a document from another". That demonstration is made with cross-boundary questions, not with a documentation page: query from the wrong perimeter and check the result is empty. If the vendor cannot describe that test, it has no isolation evidence.

Operate: what happens after the pilot

7. Who runs the system, with which skill, from which day? A successful pilot is one where someone inside the company can re-ingest a corpus, replay an evaluation, read a log and answer an unhappy user. If that person does not exist on the day of the vote, they will not exist six months later either, and the system stops for lack of hands. Ask by name: who, on what date, with what training, and what happens during holidays.

8. How does the corpus stay current, and how does a deletion propagate? A document-answering system ages through its corpus, not its model. Three gestures need a clear answer: adding, updating, and above all deleting — a document withdrawn for legal or contractual reasons must disappear from answers, including from whatever was indexed. A good answer describes the full chain, with a delay. A bad answer talks about "automatic synchronisation" without saying what happens when the source is wrong.

9. What is the full cost, models included? Subscriptions compare easily; model consumption does not. An AI project has three drifting cost lines: model calls as usage spreads, storage and re-indexing as the corpus grows, and human review time. The committee should get a usage range across three scenarios — pilot, one team, one division — not an entry price. If the vendor cannot describe the variable that makes the invoice drift, that variable will decide the budget.

Exit: what nobody likes to ask

10. Which obligations apply to us, and by when? The European AI regulation entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions: prohibited practices and AI literacy obligations from 2 February 2025, governance rules and obligations for general-purpose AI models from 2 August 2025. High-risk systems under Annex III have an extended deadline to 2 December 2027, and those embedded in regulated products under Annex I to 2 August 2028, following the political agreement on the "AI Omnibus". Since 2 August 2026, supervision sits with the AI Office and national authorities. A mid-sized company need not be a model provider to be in scope: it can be a deployer. The question to settle is therefore: in which role are we, for which use, by which date.

11. Against which framework do we assess risk, and who carries it? No single obligation replaces a company decision on acceptable risk. Public frameworks structure that decision: NIST published its AI Risk Management Framework on 26 January 2023 as a voluntary framework, and a generative AI profile, NIST-AI-600-1, on 26 July 2024. The committee can therefore demand a risk assessment against a named framework, with a named owner, rather than a ticked box. What to check is coherence: a use judged high-risk internally cannot ship with the controls of a comfort use.

12. How do we exit if the result is not there? The last question protects the other eleven: on what date is the decision reviewed, against which criteria, and what happens if the criterion is missed. Exiting requires being able to recover your data and indexed documents in a usable format, and knowing what becomes of what was produced during the project. A reversibility clause that does not mention indexes, test sets and logs is decorative: those are what make a vendor change possible without starting over.

What these twelve questions change at the vote

They do not make a project safe by magic. They move the discussion from the product to the decisions the company will have to hold: a corpus owner, a kept test set, replayable evidence, a person who operates, a review date. A committee that gets precise answers on those five points can fund an AI project with a known risk. A committee that only gets demos funds a promise, and will discover the rest when the pilot ends.

Can the committee settle for a compliance audit?

No, and the reverse is true too. An external audit checks requirements; it does not say whether the target decision improves, whether the corpus is current, or whether anyone can replay an evaluation. Compliance and usefulness are two different questions, and a project must answer both.

Should a project wait for the AI Act deadline?

No. The deadline is not a green light and excuses nothing: from 2 August 2026 the regulation is applicable and supervision is in place. What the date changes is the documentation to produce and the role to assume — deployer or provider. A project that can name its role and its use does not need to wait to start documenting.

Does the NIST AI RMF make a project compliant with GDPR or the AI Act?

No. NIST presents its framework as voluntary: it structures a risk management approach, it does not attest compliance. GDPR and AI regulation compliance come from distinct texts and distinct situations, assessed by the competent authorities and the company's advisers.

How many questions really need settling before funding?

Twelve is a format, not a standard. What matters is coverage: target decision, corpus owner, cost of error, replayable evidence, rights, operations, updates, full cost, obligations, risk framework, exit. A committee that settles those ten subjects, in its own words, has the essentials.

Can a smaller company apply the same grid?

Yes, by reducing the scale, not the questions. A small company often has no data team: question 7 then becomes a question of dependence on a provider, and question 12 a question of contract. Questions 1 to 6 stay identical, because they are about the decision and the evidence, not about company size.

Methodology and sources

• European Commission, regulatory framework on artificial intelligence, consulted on 5 November 2026. The page gives the application timeline: entry into force on 1 August 2024, applicability on 2 August 2026, prohibited practices and AI literacy from 2 February 2025, governance and obligations for general-purpose AI models from 2 August 2025, Annex III extended to 2 December 2027 and Annex I to 2 August 2028 after the "AI Omnibus" agreement, supervision by the AI Office and national authorities from 2 August 2026.
• NIST, AI Risk Management Framework, consulted on 5 November 2026. The framework is described as voluntary, published on 26 January 2023; the page states it is being revised as part of the White House AI Action Plan.
• NIST, AI RMF Generative Artificial Intelligence Profile (NIST-AI-600-1), released on 26 July 2024, consulted on 5 November 2026.

This article is an editorial decision grid: it contains no customer data, no internal metric and no promise of results. The deadlines quoted are those of official texts and must be re-checked before any contractual use, since the regulation's calendar has already changed once.

---

Preparing a committee that has to settle an AI project? Describe your context to IgnitionAI. The first conversation is meant to sort what belongs to the decision, the evidence and the exit — not to present a product.