Compliance leaders trying to modernize their review process often run up against a major roadblock: a request from the CTO to build a system in-house, using Claude or another LLM.
Your CTO isn’t wrong to ask the question, and may cite tool fatigue or budget concerns. Most technology leaders know a general AI model can summarize a contract or flag a risky phrase, and naturally think: We can build it ourselves.
If you lead legal or compliance, you’ve probably heard some version of that this year – perhaps as you were trying to make the case for a purpose-built tool. Here's a guide to navigating that conversation, with topics you should raise with your CTO and questions you can ask.
Your role in this discussion is not to win an argument, but to clearly communicate what you need: to match a human reviewer’s capability when reviewing regulated content and scale that across the entire organization, all in an intuitive workflow that’s repeatable, consistent, exhaustive, and trustworthy.
It’s true that some teams will only be convinced by trying an in-house build first; this is a guide for those who’d rather skip that step and start getting value from a purpose-built AI marketing compliance tool.
Can’t we build this ourselves?
Technically, yes. But you’d be building an application, not just writing prompts.
If you get this question, explain that there are two ways to go about it. In the first, you ask an AI model to spin up sub-agents, each mapped to a single task. In the second, you write a set of skills that map to your rules, share them with the people who create content, and have them run their own material through the model.
You’ll get a model that reads and flags content, but neither choice gives you a system around it. You’d still have to build everything else: who can change a rule, how a change gets reviewed, what the content owner sees, and where records live. This is what you want to lean into in this conversation.
Define the problem you’re trying to solve
Your CTO might ask what problem you’re trying to solve in an attempt to determine whether a tool you already have, or one you could easily build, can do the work. Answer that question by explaining that what you need is technology that can match or beat a human reviewer on regulated content and communication, and to roll it out across the entire organization so reviewers no longer read every piece themselves.
What does that look like in practice? A system that:
Reflects the risk tolerance of your reviewers, your team, and your organization
Thoroughly understands your business context, including your products, position, and risk over time
Runs in a workflow that is intuitive, repeatable, consistent, exhaustive, and trustworthy
A model that is good at flagging issues covers some of these requirements, but the true test for an in-house build is whether or not it covers all of them, for every team that creates and submits content for review. You can raise awareness of these needs by asking for agreed-upon requirements before going any further with an in-house build.
Question to ask your CTO: Can we agree on a list of requirements before we build?
Timelines and responsibilities
Make your CTO aware of some of the practicalities involved in building a tool of this complexity with three key questions. To bring home the impact, ask for a budget discussion so everyone understands DIY rarely, if ever, means “free.”
Who will own the build, and how will this be prioritized? Building a compliance tool will compete with everything else on the CTO’s list, so direct the conversation back to that. "We'll build it" needs an owner or project manager, a timeline, and ranked prioritization.
When will it go live? Starting with a purpose-built tool today means it can begin delivering results in a few weeks. A build leaves the problem – growing content volume, overwhelmed reviewers, missed regulatory issues – unsolved until it’s built and tested.
Who will maintain it? Rules change, products change, and AI models change. Someone within the enterprise has to keep the skills, the knowledge base, and the integrations current. That translates to developer resources devoted to a tool that isn’t your company’s core business.
Question to ask your CTO: Who owns it, when does the first version reach our reviewers, and what will we stop doing to make room for this build?
Bonus question: Can we put numbers on all of these before making a decision?
Getting risk tolerance right
This is where many internal builds falter. Out of the box, a general model is conservative, with no sense of your business’s risk tolerance. It flags things a reasonable person with context about your company would let through.
While it’s true you can adjust risk tolerance for one reviewer by providing the model with more context, getting it right for the whole organization requires a larger engineering lift, and even a complex build will struggle to continue improving as the reviewers make decisions. In short, general AI workspaces simply aren’t built for this use case.
Your organization’s applicable legislation and internal guidelines could help you establish some level of risk tolerance, but there would be a gap: the knowledge nobody has written down. This can only come from learning your reviewers’ past decisions.
AI models for general use tend to flag issues very conservatively, but rather than keeping you safe, this can be a negative. Allowing an in-house build to over-flag doesn’t solve the problem of long review queues and delays from multiple iterations. By raising too many issues, it teaches both content owners and reviewers to stop reading what it says.
Question to ask your CTO: How will the system learn our risk tolerance?
Ensuring consistent feedback for every marketer
An in-house build won’t ensure consistent feedback by default. If you put the same content into a general model three or four times, you’re likely to get different results each time.
The reason is latitude – when you give a model a broad task, it can reason down many valid paths. If you narrow the task with additional context, the amount of variation drops, but won’t disappear entirely. The way to get closer to a consistent result is one directed task, plus guardrails, plus context on how similar content was handled in the past.
Compare these three versions of the same instruction:
Find all misleading content.
Find misleading content relevant to performance claims in ETF marketing.
Find misleading performance claims for this product, in this context and region, including the kinds of chart errors marketers have submitted before.
Each step gives more consistent results than the one before, but there’s a catch: Every team has to use the same structure and the same prompt every time. On the surface, it seems simple enough, but it’s difficult to enforce in practice. Depth also matters: asking a model to cover fifteen tasks at once gives worse results than asking it to cover one, because each task gets more time, depth, and context.
If marketers get different answers on the same issues, the review loses validity, and the inconsistency will degrade trust in the model over time. That’s not a path to successful adoption of a tool your in-house team spent time and resources to build.
Question to ask your CTO: How will we ensure consistent review, so two people submitting the same piece get the same answer?
Building trust and ensuring adoption
Technology leaders want to know that the tools they buy or build will be good investments, trusted and used by the teams who need them. Lean into the trust aspect here, building on issues you’ve already raised, like the ability to tune risk tolerance and ensure consistent feedback. Add the need for a persistent record that reviewers and content owners can access.
In-house builds won’t automatically provide digestible records, and sharing an LLM chat or multi-page report only creates more work for teams who are already dealing with a backlog. AI models also won’t fix some of the most common recordkeeping issues, like tracking who reviewed what, comparing marked-up versions against what was accepted, and emailing or sharing links without tracking or clearly defined ownership.
Regulated firms may also have to provide regulators with records that answer questions like:
Was every line checked against every rule that applies?
Was anything skipped?
Can the review be reproduced with the same result?
If reviewers and content owners can’t trust the model internally nor externally, the chance of team-wide adoption is slim. Whatever investment your organization has made won’t achieve a return, and the core problem will still persist.
Questions to ask your CTO: If a regulator or an executive asks why a piece was cleared, what will we show them? What steps will we take to ensure the team uses anything we build?
The cost of not hitting the mark
Beyond limiting how many people will use and trust your in-house build, spending more time and resources to build a non-functional tool has other consequences.
Compliance leaders cite hallucinations, high degrees of inaccuracy, lack of ability to review some types of specialized content, and the need for multiple human reviews as reasons to set aside the quest for an in-house tool. But perhaps the biggest risk is that something critical will be overlooked, exposing the organization to audits, fines, and potential enforcement, not to mention a drop in customer satisfaction and public trust.
Questions to ask your CTO: How long is the runway to determine whether or not this works? And what is our plan if we decide it doesn’t?
What does a purpose-built tool do that an in-house build can’t?
Just as it’s fair for your CTO to ask whether an in-house build is possible, it’s also fair to ask for proof that a purpose-built tool will meet and exceed the expectations you’ve laid out.
Choosing the right vendor: How to run a smart RFP
Use your list of CTO questions as a roadmap for conversations with vendors, too.
Out of the box, Haast meets the requirements for highly tuned risk tolerance, ability to scale across teams and organizations, workflow integrations, consistency, exhaustiveness, and trust. Teams gain the ability to approve assets 60% faster, with 40% fewer iterations.
Top providers comparison: Best marketing compliance software
How to have the build vs. buy conversation with your CTO
If you approach this as a business conversation driven by thoughtful questions, it’s likely your CTO will decide for themselves (or be effectively persuaded!) that an in-house build isn’t worth it.
To review, here’s a list of questions to ask your CTO in a marketing compliance build vs. buy conversation:
Can we agree on a list of requirements before we agree to build?
Who will own the build and ongoing maintenance?
Timeline – when does the first version reach our reviewers?
Where does this fall on the prioritization list? What will we stop doing to make room for this project?
Can we put a budget on an internal build before making a decision?
How will the system learn our risk tolerance, and how will that improve over time?
How will we ensure consistent review, so two people submitting the same piece get the same answer?
If a regulator or an executive asks why a piece was cleared, what will we show them?
What steps will we take to ensure the team uses anything we build?
What’s the timeline for deeming this a success or failure, and what’s plan B?
At the end of your conversation, you’ll either have a plan for an ambitious in-house build or a solid case for starting with a purpose-built tool today. Interested in learning about Haast? Book a product tour.
Team Haast
