Many companies ask themselves this question first, and rightly so: you already have a general-purpose AI assistant under an enterprise licence, a team capable of building document search, and your documents. This page compares the two approaches on the same fourteen criteria as our other comparisons, without passing judgement on the quality of the general-purpose tools on the market: they do very well what they are designed for.
Organisations whose questionnaires are few or carry little commitment, who have a technical team available over the long term, and whose internal documentation is already well kept and versioned. It is also the right answer for internal search or drafting needs.
Organisations whose answers legally bind the person who signs them — tenders, security questionnaires, DDQs, audits — and who need replayable traceability, maintained regulatory expertise and sovereign deployment without tying up their IT department.
Both approaches answer the same need, so the comparison is a fair one. Survey carried out on 25 July 2026.
Five core-category criteria, where a well-run internal build reaches parity, then nine differentiators. Our own limits appear in our column.
Pricing on quotation, with no public figure. No unlimited customisation of the data model: the platform imposes its evidence mechanism, and that is a deliberate choice; an internal development, by contrast, does exactly what you decide.
Producing relevant text from your documents is the first third of the work. The other two thirds are traceability: citing the exact page, knowing the applicable version, detecting that another document says the opposite, scoring how solid the answer is, enforcing named approval, and replaying the whole thing two years later.
It is this layer that separates a draft from an answer you can be held to, and it is this layer that takes months to build.
An internal tool works on the day it is delivered. After that, frameworks evolve, clients change their formats, a portal modifies its fields, and the person who wrote the code moves to another role.
The question to settle is not “are we capable of building it?” — the answer is often yes — but “do we want to maintain it for five years?”.
A general-purpose assistant does not know what evidence a sector standard expects, nor that a vague wording about a testing frequency is enough to lower a mark. It produces a plausible answer.
That kind of knowledge does not come from a well-written instruction: it is built from practising the trade. Where ours comes from.
The real issue
It has actually become the easy part, and that is what makes the decision misleading: a competent team gets a demo that answers questions within three weeks. The gap does not show there. It shows the day the answer goes out to a client, and it comes down to five points. None of them is a matter of engineering talent.
An in-house assistant produces answers that seem right, and that is exactly the problem: nothing tells you which ones are not. Without an explained score, without an abstention threshold, without cross-checks, human review covers one hundred per cent of the answers, so the promised time saving disappears, or the review is rushed and the risk goes into production.
The question to ask the team: on which answers do you recommend we not rely on you, and how do you know?
Knowing what an assessor expects behind a question, recognising a trick question, spotting the implicit commitment a wording creates, knowing the level of evidence that satisfies a given framework: none of this comes from describing the trade to the model. It is what our agents have absorbed, and it is the part nobody can recreate without having done the job.
The question: who, internally, knows how to write an answer that legally binds the signatory, and how much of their time will they devote to it?
An in-house tool answers with the rules as they stood on the day it was built. Yet texts move, and assessment grids follow. Monitoring 193 jurisdictions and updating the grids when a text changes is not a development: it is a permanent function, with people reading texts all year round. No internal team takes that on for its own use alone.
The question: who detects that a requirement has changed, and how quickly is the grid corrected?
Returning the client’s Excel workbook in its original formatting, drop-down lists included. Filling in a portal through an extension. Managing permissions, approval circuits, the audit trail, document versioning, incident recovery, data return. There is nothing intelligent about this list, and it is what consumes the person-years, far more than the model layer.
The question: who maintains all this in three years’ time, when the team that wrote it has moved on to something else?
It is the weightiest trade-off in an in-house project, and it is often settled by default. Calling a remote model through an application programming interface means sending the content of your policies, contracts and audit evidence to a third-party service, under a law that is not necessarily yours, wherever your own hosting is located. Running a model locally puts sovereignty back under your control, but shifts the operating burden onto you: hardware, updates, continuous quality assessment, and a performance gap to close with your own resources.
Both paths are defensible. What is not defensible is selling internally a project that is “sovereign because it is hosted in France” while its requests go to a foreign service: that is exactly the confusion the sovereignty page describes, and a CISO spots it with one question.
The question: where does the computation run, under which law, and who can technically read the request at the moment it is processed?
sovereignty pageThe concession, because it is true: for a draft, an internal summary or a first version meant to be entirely rewritten, an in-house assistant plugged into a general-purpose model does the job, and building it is an excellent learning experience. The line is not technical difficulty. It is the signature.
Frequently asked
For a draft, a summary or internal search, yes, and it is often the right decision. The line is the signature: as soon as an answer leaves the company and binds its signatory, you need the cited source, the version, the score and the named approver.
A useful first version can be built in a few weeks. What takes months is document versioning, reliable extraction from imposed formats, the approval workflow, the explainable score and the replayable history, and then maintaining them.
Not automatically, and this is the most common blind spot: the documents can stay with you while the processing goes to a third-party inference service. The question to ask of your own architecture is the same one to ask of us: where does the computation happen, and under which law? See sovereignty.
Yes, and many of our clients do: the general-purpose assistant for day-to-day and internal work, the platform for what goes out and commits the company. The two uses do not compete for the same ground.
Take the hardest question from your last questionnaire, put it to both, and compare not the quality of the text but what comes with it: the page cited, the version, the score, and what each one answers when the source does not exist.
Comparison drawn up on 25 July 2026. The “in-house development” column describes what an internal project involves when it relies on a general-purpose AI assistant under an enterprise licence and a document base built in-house; it attributes no characteristic to any named product. The actual capabilities of such a project depend entirely on your architecture choices and on the contractual terms of your model provider: check them in your contract.
A factual error on this page? Write to us: we correct within 5 working days and date the correction. Report an error.
Bring the hardest question from your last questionnaire. We process it in front of you, on your documents: you judge what comes with the answer.