Build vs Buy: A Sanitisation Tool Guide

Last updated: July 2026

Building an internal sanitisation tool means putting your own engineers on the job of detecting and removing client-confidential content from decks, rather than buying software that already does it. For most consulting firms, buying wins. Not because of ambition or budget. High accuracy on confidential content is an iterative engineering problem with a realistic 12 months+ build, not a sprint your KM or AI team can absorb alongside its day job.

That's the short answer. The rest of this piece is the reasoning, including where building genuinely is the right call.

Sanitisation is the term we'll use throughout (redaction is the same job, more common in legal and government contexts; blinding, scrubbing, anonymisation and de-identification all point at the same problem under different labels). Whichever word your firm uses internally, the build-vs-buy question is identical.

Start with the strategic question, not the technical one

Before any timeline or budget conversation, ask this: is building and maintaining confidentiality-detection software core to your firm's strategy, or is advising clients core to it?

For almost every consulting firm, the answer is the second one. Building software that reliably tells confidential from non-confidential content, across every practice area, document type and client relationship you have, is a standing ML engineering function. Running one of those isn't adjacent to what a KM or AI team is for. It's a different job, with a different hiring plan, a different management structure and a different set of things that can go wrong.

The MBB firms have built internal tooling for exactly this, or are in the process of trying to, and even they are hitting significant frustrations getting it production-ready: the tooling generally just catches names and logos, and getting it to understand consulting context is proving genuinely hard. They can at least carry a permanent engineering bench and amortise the effort across a much larger deliverable base. Most firms don't have that bench, and building one specifically for this problem is a significant commitment in its own right.

The realistic timeline is 12 months+, not a sprint

A production-grade internal tool needs far more than a demo-quality detection model, but be honest about where the time goes. The review workflow, where consultants check and override decisions, is the easy part: it's UI work, and a competent team can ship it in weeks. The genuinely hard parts sit underneath. Detection that understands consulting context rather than just spotting names and logos. Entity resolution across a whole deck, so the tool knows a margin figure deep in the appendix belongs to the client identified on slide 2. A PowerPoint round-trip that works inside the file's internals, cleaning embedded chart data, speaker notes and other hidden traces without breaking formatting or embedded charts. Add the audit trail for compliance and enough polish that partners will actually use it rather than route around it, and the UI is the least of the work.

It's those hard parts that set the timeline: 12 months+ for a firm that already has engineering capacity to point at it. Most firms don't have that capacity sitting idle. They'd be hiring into the build, which pushes the start date out further before the clock even begins.

Meanwhile, the AI programme this tool is supposed to unblock is waiting on it.

The prototype trap

Here's the part that catches most internal builds out. A prototype that catches the obvious identifiers in a deck is genuinely easy to build. A few weeks with an LLM API and a basic interface will catch client names, logos and other surface-level markers. It'll look like a working product in a demo.

That's the wrong finish line.

The content that actually causes a breach isn't the client's name. It's the confidential detail that has no name attached to flag it: a margin figure, a pricing structure, a strategic rationale, a number sitting quietly on slide 14 that reads as generic until you know whose deck it came from. Getting reliably high accuracy on that category isn't a prompting problem you solve once. It's an iterative engineering problem: building evaluation sets, running regression tests every time you touch the model or the prompt, tuning against false negatives (a miss is a breach) and false positives (over-redaction destroys the reusable IP you were trying to preserve), and doing all of that across every sensitivity type, industry vertical and document structure your firm produces.

That's a test-and-evals pipeline. It's not a weekend project, and it doesn't end when the prototype demos well. It's the ongoing cost of the tool, not a one-off milestone on the way to it.

The maintenance burden nobody budgets for

Two things keep moving after launch, and both cost engineering time indefinitely.

First, new content structures, industries and edge cases keep surfacing. Every new client sector, every new deck format, every new type of embedded content is a fresh case your detection logic hasn't seen. A vendor amortises that maintenance across every client it serves. An internal team carries all of it alone, for one firm.

Second, the underlying models move fast. An internal team competing for engineering time against client-facing priorities will not keep pace with model churn, and accuracy degrades quietly in the background until someone notices the tool is missing things it used to catch.

Neither of these shows up on the original build estimate. Both show up in the first year of running it.

Opportunity cost is the real number

Every month spent building is a month your KM or AI team isn't doing the things that actually justify the AI investment: curating the knowledge base, rolling out the tools, running adoption. The engineering time going into a detection pipeline is engineering time not going into the programme sanitisation exists to serve.

Run the comparison honestly: what does a won project at your average deal size look like against a year of engineering salary spent building and maintaining something a vendor already sells. For most firms, that comparison doesn't favour building.

When building genuinely makes sense

It would be dishonest to argue building is always wrong, so here's when it isn't:

• You're operating at genuine scale, with a standing ML engineering function you'd be running anyway, and confidentiality detection is one more workload you can add to an existing bench rather than a new one you have to grow from zero.
• Your deliverable base is narrow and stable enough that a simpler pattern-matching approach covers most of your actual risk, and you're comfortable with the accuracy ceiling that comes with it.
• You have a specific, unusual data-handling constraint that no vendor's deployment model meets, and building is genuinely cheaper than the alternative of doing nothing.
• You want the IP long-term and have costed the 12 months+ build plus the ongoing evals pipeline against years of licence fees, and it still comes out ahead.

If none of those describe your firm, the honest scorecard below is the one that applies.

The scorecard

	Build internally	Buy
Time to first use	12 months+, longer if hiring into it	Weeks
Accuracy on non-public content	Starts at names and logos; requires an ongoing evals pipeline to move past it	Purpose-built and maintained against it from day one
Maintenance	Falls entirely on your team, competing with client work	Amortised across every client the vendor serves
Model churn	Your team absorbs it, unfunded, indefinitely	Vendor's job to keep pace
Opportunity cost	Engineering time diverted from the AI programme itself	None; the programme starts sooner
Where it fits	Firms with a standing ML bench and genuine scale	Firms whose core business is advising clients, not building detection software

The Azure-tenant question deserves a note here too, because it's often the real reason "build" gets raised. If the pull toward building is wanting everything inside your own Microsoft environment, that's available without building or maintaining the detection engine yourself: deploy a vendor's tool into your own Azure tenant, with processing staying inside your tenancy, and you get the ecosystem fit without the 12 months+ build.

The honest bottom line

A prototype that catches the obvious identifiers in a deck is easy. A production system that catches the content with no name attached to flag it, and keeps catching it as your content and the underlying models change, is a standing engineering commitment. Even the firms operating at the largest global scale are finding that hard. Most firms are better served putting that engineering time into the AI programme the sanitisation step exists to unblock, and buying the piece that isn't core to what they do. See the AI sanitisation software category page for what a purpose-built platform actually covers.