Compliance technology has become the operational backbone of the modern ethics and compliance program. When technology works, it can make compliance faster, more consistent, measurable, and embedded in business operations. When it doesn’t, the consequences show up everywhere: spreadsheets, manual workarounds, disconnected data, frustrated employees, and compliance professionals spending time administering technology rather than managing risk.
That makes buying compliance technology more than an IT procurement exercise. It is a compliance program effectiveness issue. One commentator on this aspect of AI for compliance is Andrew McBride, founder of the consulting firm Integrity Bridge LLC. McBride recently released Recommended Practice for Buying & Selling Compliance Technology, based on surveys of compliance technology buyers and vendors. Its findings illuminate a fundamental imbalance in the marketplace. I can safely say this paper is the standard for compliance professionals evaluating and purchasing AI-based technology.
CCOs buy compliance technology infrequently. Vendors sell it every day. That imbalance matters. Compliance teams can be oversold on functionality. Vendors can become trapped in opaque procurement exercises. Business requirements can become disconnected from technical requirements. AI capabilities can be accepted without sufficient governance. Contracts can focus extensively on getting into a system while ignoring how the company will eventually get out. For the CCO, the lesson is straightforward. If you want to run compliance like a business, you must learn to buy compliance technology like a business. This is where McBride comes in.
Start With Strategy, Not Software
As a CCO, start with a documented compliance technology strategy aligned with business operations. McBride sees three operational layers for that strategy.
Compliance-owned technology includes platforms compliance directly manages, such as Codes of Conduct, training, whistleblower systems, investigation case management, and workflows for gifts, entertainment, and conflicts.
Compliance-shared technology includes systems operated across functions, such as third-party due diligence, transaction monitoring, and communications monitoring.
Enterprise dependency technology includes compliance systems that may not be owned but depend on ERP, CRM, HRIS, procurement, and financial platforms.
This third category is particularly important. A CCO may believe the company has a third-party risk problem when the real issue is poor vendor master data. Transaction monitoring may generate noise because underlying financial data is inconsistent. Technology strategy therefore begins with understanding the compliance program’s architecture.
Know What Compliance Really Costs
Here, McBride frames the question as, ‘What is the total cost of ownership? ‘How many screening tools are independently licensed by Compliance, Procurement, Finance, Credit, and Legal? How many employees maintain spreadsheets? How many hours are spent chasing approvals or reconciling systems? How much compliance talent is consumed by administration rather than risk management? Those costs matter because an inexpensive system can become extraordinarily expensive once you include the human infrastructure required to run it.
This leads to the recurring question: buy, build, or assemble? Internal IT may propose building custom tools. Sometimes that works, but the calculation must include maintenance, upgrades, staffing, cybersecurity, documentation, and key-person risk. Another option is configuring technology the company already owns. That may reduce licensing costs, but “we already own it” does not mean “it is free.” Configuration, integration, testing, administration, and support still cost money.
Commercial software offers established products and vendor-supported roadmaps, but buying software does not eliminate implementation challenges. Apply the same economic discipline to all three options. Don’t compare the sticker price of commercial software with an internal solution whose real costs have never been calculated.
AI Changes the Conversation
AI is moving into transaction analysis, investigation scoping, interview preparation, monitoring, and other compliance workflows. The opportunity is substantial. So is the governance challenge. The Integrity Bridge research presents an interesting picture. AI use appears widespread, but governance and confidence have not necessarily kept pace. Only about one in four compliance teams surveyed had established a formal governance framework. Fewer than half could articulate how AI demonstrably improved compliance outcomes. Only 41 percent of compliance leaders trusted AI-driven outputs for operational decisions.
At the same time, 84 percent reported efficiency gains, while fewer than half reported actual cost savings. That distinction between efficiency and effectiveness is critical. Doing something faster does not necessarily mean doing it better. The CCO should not simply ask, “Does this product use AI?” The better question is, “What compliance outcome does the AI improve, and how can we demonstrate it?”
AI Governance Starts Under the Hood
“AI-powered” is not a meaningful technical specification. McBride advises that compliance should understand what happens under the hood. Once again, he is spot on. Ask questions such as, “Which model is being used?” What information goes into it? What comes back? Is customer information retained? Can corporate data be used for training? Does a third-party model provider receive the information?
These are compliance governance questions because the data may include investigations, employee information, third-party records, or financial information. The contract should address how that information is handled and establish appropriate restrictions on the use of corporate data and queries.
Next, a series of questions about where the AI can fail. Here McBride suggests: How does the system prevent cross-tenant data leakage? How does it identify unsupported statements, hallucinations, or fabricated citations? What happens when malicious instructions are hidden inside uploaded documents? Most importantly, does the system recognize when it lacks sufficient confidence and escalate the matter to a human?
One of the most important characteristics of compliance AI may not be its ability to answer questions. It may be its ability to recognize when it should not answer them.
Keep Humans in the Control Environment
Agentic AI raises the stakes because technology moves from providing information to taking action. But this requires clear authority boundaries. What systems can the agent access? What records can it change? What decisions can it make? Which actions require approval?
Certain compliance decisions should remain subject to documented human authorization. Closing an investigation, changing third-party screening rules, or approving high-risk onboarding are obvious examples. This is where AI governance becomes internal controls. The organization should demonstrate not merely that humans are theoretically “in the loop,” but where human intervention occurs, who has authority, what approval evidence is retained, and what happens when the AI crosses a defined threshold.
CCOs must also understand AI economics. Traditional platforms may be priced by employees, users, or third parties. AI functionality can introduce consumption pricing tied to tokens, documents, searches, or API calls. Model realistic usage and negotiate appropriate spending caps, alerts, overage controls, and consumption rates.
Turn the RFP Into a Governance Exercise
A good RFP does more than collect vendor responses. It forces the organization to define what it actually needs. McBride highlights vendor frustration with “phantom RFPs,” where an incumbent has effectively been selected, or the process is used primarily to gain renewal leverage. A credible RFP must instead be transparent, disciplined, and operationally grounded.
Start with Procurement. Understand source-to-pay requirements, spending thresholds, cybersecurity reviews, privacy requirements, and contracting procedures before bringing vendors deep into the process. Then give vendors meaningful operational information: employee populations, transaction volumes, existing systems, data maturity, integrations, geographic requirements, and workflow constraints.
Most importantly, force precision into vendor answers. Require vendors to classify functionality as:
- Available out of the box.
- Available through configuration.
- Available through a named third-party integration.
- On the roadmap with a committed date.
- Not supported.
That discipline can dramatically improve an evaluation and create a record of what was actually promised.
Stop Buying Features. Test Controls.
Feature checklists have limits.
McBride suggests that a better test is a scenario. Suppose a critical third party is added to a sanctions list overnight. Ask the vendor to show exactly what happens. Ask questions such as, “How is the alert generated?” Who receives it? How is it prioritized? Who can override it? How is the matter escalated? What evidence is captured? What appears in the audit trail?
Now you are not evaluating a feature. You are evaluating a control. The same principle applies to sandboxes. A generic vendor sandbox tells you relatively little. Require a guided environment configured around your workflows using synthetic or anonymized data. Make users perform the work. That is where implementation problems begin to reveal themselves.
Look Under the Hood Before You Buy
A beautiful interface can be seductive, but buying compliance technology based primarily on user experience is like buying a house because you like the countertops without checking the plumbing. However, before you make a final selection, conduct due diligence around security controls, hosting, uptime, integrations, implementation resources, and data portability.
Review relevant SOC 2 Type II controls. Speak with peer customers. Consider asking to speak with a customer that recently left the platform. Just as importantly, interview the people who will actually implement the product. The team delivering the sales demonstration may not be the team handling implementation. Know who shows up after the contract is signed.
Begin the Relationship by Planning the Exit
Perhaps the most overlooked element of compliance technology contracting is the exit. Companies spend enormous time determining how information will enter a system and surprisingly little determining how they will get it back. A CSV containing basic fields may not recreate an investigation file or preserve the history of a third-party approval. It may not capture attachments, comments, timestamps, escalations, approvals, or audit trails.
Before signing, define export requirements. Ask questions such as: What formats will be provided? What metadata will be preserved? What happens to attachments? Will the audit trail survive? How long will migration assistance remain available? What will extraction cost? When will the vendor delete remaining copies? Understand how you will leave a compliance technology provider before deciding to join it.
The CCO’s Technology Mandate
Compliance technology doesn’t succeed or fail when Legal finishes negotiating the contract. The outcome is largely determined earlier. Did Compliance understand the business problem? Did it know the true cost of the existing process? Did it understand its data? Did it challenge AI claims? Did it test failure modes and workflows? Did it involve Procurement, IT, Privacy, Security, Legal, and the business at the right points? Did it negotiate for implementation, operation, and exit?
Those questions turn technology procurement into compliance governance. Compliance professionals spend their careers asking businesses to operate with transparency, accountability, documentation, fairness, and integrity. Compliance should bring those same principles into the technology marketplace.
Define what you need. Understand what it costs. Test what the vendor claims. Document what was promised. Build controls around AI. Measure whether the technology improves the program. Make sure you can get your data back when the relationship ends. That is what it means to run compliance like a business.
Practical Takeaways
For the CCO, the mandate is clear: build the strategy before selecting the technology; calculate the Total Cost of Ownership rather than the license cost; treat AI as a governance and internal controls issue; test workflows rather than watch demonstrations; diligence the implementation team; and negotiate data portability and exit before signing.
For boards and senior management, the oversight question is equally straightforward: What compliance risk is this technology addressing, how will management measure whether it improves program effectiveness, and what controls govern its use?
The answer tells you much more than whether Compliance has purchased the latest technology. It tells you whether the organization is building a technology architecture that can support an effective compliance program.
If you do not follow Andrew McBride on LinkedIn, you should. He is leading the discussion on the practical aspects of putting the right AI tool in place for you and your organization. His organization will be displaying at this week’s SCCE CEI, so drop by the Integrity Bridge and find out why I think he is the go-to guy in this area.
