To vet an AI vendor for debt collection compliance, treat the tool as a controlled part of the collection operation: define its permitted use, map it to applicable communication and notice requirements, test consumer-facing outputs, preserve evidence, and keep people accountable for exceptions. A vendor’s claim that its product is compliant is not a substitute for a documented review of the specific deployment.
Start with scope, not the product demonstration
This article addresses AI used in United States consumer debt collection. The CFPB’s Regulation F overview explains that Regulation F implements the Fair Debt Collection Practices Act (FDCPA) and prescribes federal rules for activities of debt collectors as defined in that law. It covers subjects including collection communications, validation information, disputes, record retention, and state exemption programs.
That scope matters when evaluating a vendor. A collection agency, debt buyer, creditor, servicer, and technology provider may have different roles in a workflow. Do not assume that a vendor’s contract description, an automation label, or a generic compliance statement resolves whether a particular rule applies. Identify the legal entity using the tool, the account type, the communication channel, the states involved, and the decisions the system can make before approving a use case.
Define what the system actually does
“AI” can describe very different tools. A rules-based interactive voice response (IVR) system generally follows preapproved branches. A generative voice or chat system can produce new language in response to a conversation. An agent-assist tool may draft a suggested response while a person remains the sender. These differences affect the review: a controlled script calls for script governance, while an open-ended system needs boundaries, scenario testing, and reliable escalation.
Ask the vendor to demonstrate the production architecture rather than only the user interface. The organization should be able to state, in plain language, whether the system generates text or speech, retrieves account data, takes actions, routes communications, changes its behavior from feedback, or merely presents approved content. If the vendor cannot explain these functions and their limits, the buyer cannot reliably assign controls.
Turn collection requirements into system controls
Controls should be specific enough to test. For example, for covered debt collectors, 12 CFR 1006.14 sets presumptions related to telephone-call frequency for a particular person and debt: no more than seven calls in seven consecutive days, and no call within seven consecutive days after a telephone conversation, subject to stated exclusions. A dialing or voice-AI workflow should therefore be able to distinguish the person and debt, count relevant calls, record conversations, and apply the organization’s legal interpretation of exclusions.
Likewise, 12 CFR 1006.34 requires validation information in the circumstances it covers, including specified information about the collector, debt, creditor, itemization date, and current amount, as well as consumer-protection information. If a vendor generates or assembles a validation notice, the review should confirm that the approved template is controlled, the account-data fields are sourced and reconciled, and changes cannot silently omit required content.
| Workflow | Control question | Evidence to retain |
|---|---|---|
| Outbound calls or voice AI | Can the workflow apply the approved contact rules to the correct person and debt? | Call records, configuration history, test cases, and exception logs |
| Notices and written messages | Does the system use approved content and verified account data? | Template version, data mapping, samples, and approval record |
| Disputes, requests, or preferences | Does the tool recognize a signal it is allowed to handle and route it promptly when it is not? | Scenario results, routing rules, and queue or case records |
| Uncertain or unexpected conversation | Does the system avoid inventing an answer and transfer to an authorized person or process? | Escalation criteria, conversation samples, and quality-review findings |
| Model, prompt, or integration change | Is a change reviewed and regression-tested before release? | Change ticket, test results, approval, and rollback plan |
Use a vendor review that covers governance and evidence
The NIST AI Risk Management Framework is a voluntary framework intended to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. It can be a useful organizing structure for a vendor review, but it is not a legal safe harbor or a compliance certification.
Govern
Assign an internal owner for the use case and identify who can approve prompts, scripts, templates, model changes, and exceptions. The contract should address permitted data uses, access controls, subcontractors, incident notification, audit cooperation, retention, and the ability to export records if the relationship ends.
Map
Document each step from account-data intake to consumer interaction and back to the collection system. Include decision points, data sources, communication channels, handoffs, and situations the tool must not handle. Mapping exposes whether a proposed “assistant” is actually sending messages, initiating calls, or making consequential workflow choices.
Measure
Test realistic and adverse scenarios before launch. Include incomplete account data, a consumer who disputes information, a request that does not fit the tool’s permitted scope, language the system does not understand, and an attempt to draw the system into an unsupported answer. Test results should be reviewed by the business owner and the appropriate compliance, legal, security, and operations stakeholders.
Manage
Set thresholds for pausing the system, define human escalation paths, monitor production samples, and investigate recurring failures. Preserve the version of the model or configuration, the approved prompt or script, relevant source data, output, actions taken, reviewer findings, and remediation. These records make it possible to investigate a complaint or reproduce a decision after a vendor update.
Questions that distinguish evidence from promises
- Which functions are rules-based, which are generative, and which actions can the tool take without a person approving each one?
- What account data does the system receive, where is it stored, and is it used to train or improve any model?
- Can the buyer restrict the system to approved templates, knowledge sources, and communication channels?
- What happens when the system is uncertain, receives a dispute-related statement, or encounters a request outside its scope?
- What logs are available for inputs, outputs, routing, configuration changes, access, and vendor support activity?
- How are model, prompt, integration, and policy changes announced, tested, approved, and rolled back?
- Can the vendor provide customer-specific test results and explain known limitations rather than making an unqualified compliance claim?
Implementation limits and human review
AI may help standardize narrow tasks, but it also creates new ways for a workflow to misstate information, use the wrong data, miss a consumer signal, or operate outside an approved boundary. The appropriate controls depend on the deployment and on applicable federal and state law. Obtain qualified legal and compliance review before using consumer-facing AI or changing an existing collection workflow, particularly where calls, texts, emails, notices, consumer data, disputes, or account decisions are involved.
For related operational context, see The Tech Stack Mandate: Automating the Collection Lifecycle and The Algorithmic Liability Mandate: AI Compliance Protocol.
Frequently asked questions
Will AI replace debt collectors?
AI can automate or assist discrete tasks, but it does not remove an organization’s responsibility to follow applicable law or supervise its collection operation. Consumer-facing AI should have defined limits, escalation paths, and ongoing testing.