The ERISA risk nobody talks about: why building benefits AI in-house could be a personal liability problem for your plan sponsor

What is ERISA, and why should teams building benefits AI care?

ERISA stands for the Employee Retirement Income Security Act. It's a federal law governing employer-sponsored benefit plans, and it establishes fiduciary duties for anyone involved in administering those plans.

Here's what catches most technical teams off guard: fiduciary status under ERISA is based on the functions you perform, not your job title or intentions. The legal term is "functional fiduciary," and it means that if you build an AI tool that exercises discretionary authority in how it interprets plan language and guides employees, the people responsible for that tool, from the plan sponsor who authorized it to the engineering leaders and administrators who deployed it, may have fiduciary obligations whether they designed it that way or not. 

And fiduciary liability under ERISA is personal. It doesn't just land on the company. The plan sponsor is always the fiduciary. But the liability can also reach the individuals who operationally deploy a poorly governed AI tool without adequate expertise or oversight, whether that's a named plan administrator, a benefits committee, or the HR leaders who greenlit the project. That's personal liability, not just corporate exposure, for specific people in your organization. If you're an engineering leader evaluating this project, that should change how you think about the risk.

Why benefits AI is different from every other internal tool you've built

Most internal AI tools operate in a forgiving environment. If a chatbot gives a bad answer about your company's PTO policy, someone catches it and you push a fix. Nobody gets sued. The blast radius of a wrong answer is small and temporary.

Benefits guidance is fundamentally different.

The stakes are financial and medical. When an employee asks "which plan covers my daughter's medication?" or "how does my deductible accumulator work?", they're making real decisions about their family's healthcare and their household budget. A wrong answer can cost someone thousands of dollars or delay necessary medical care.

The scale of impact is different too. If your internal tool misreads a formulary tier or gets accumulator logic wrong during open enrollment, that error doesn't affect one employee. It can affect thousands, all making decisions based on what your tool told them.

And then there's ERISA, which changes the calculus entirely.

The "functional fiduciary" problem

The question that matters under ERISA isn't "did we intend to act as a fiduciary?" It's "did the tool exercise discretion in interpreting plan terms and providing guidance to employees?" If the answer is yes, the people who built and operate that tool may be fiduciaries in the eyes of the law.

Most engineering teams will instinctively respond: "We'd just provide information, not make decisions." I understand the impulse. But the line between informational and discretionary is far blurrier than it appears. If your AI tool takes ambiguous plan language, interprets it, and gives an employee a specific answer about what's covered, what their cost will be, or which plan is the better fit, that looks discretionary. Courts have gone both ways on where exactly the line falls, which is precisely the problem. Ambiguity here means litigation risk.

Another common response: "We'd add a disclaimer." This one worries me more, because it reveals a misunderstanding of how ERISA works. You can't waive fiduciary duties with a terms-of-service page. And adding a 'consult your plan documents' disclaimer doesn't make a “guidance tool” an “information tool” if it's functioning like one. ERISA's protections exist for plan participants, and those protections aren't something you can disclaim in a footer.

What personal fiduciary liability actually means

Under ERISA Section 409, a fiduciary who breaches their duties can be personally liable to make good any losses to the plan resulting from the breach. This isn't theoretical. ERISA litigation is common, and the Department of Labor actively investigates fiduciary breaches.

For an engineering leader, this creates an uncomfortable situation. You build an AI tool as a technical project. It starts answering benefits questions. It gets something wrong about an HSA contribution limit, or it misinterprets a plan's coordination of benefits rules, or it gives incorrect guidance about a prior authorization requirement. Employees rely on that guidance and make decisions based on it.

Now a plaintiff's attorney, or the DOL, starts asking: What benefits expertise did the team that built this have? How did you validate the accuracy of the guidance? What's your ongoing monitoring process? Who is accountable for the outputs?

The engineering team created the risk. But the fiduciary exposure lands on the plan sponsor, and on the individuals responsible for plan administration, who put an ungoverned tool into production. Those questions are much harder to answer when the tool was an internal engineering project than when it was a vetted vendor relationship with documented diligence.

The domain complexity compounds the legal risk

Even setting ERISA aside, benefits AI is genuinely hard to build well. I know this because my team does it full-time, and the complexity still surprises us.

Benefits plan documents are dense, inconsistent, and full of provisions that interact with each other in non-obvious ways. A Summary Plan Description for a single medical plan might be 80 pages. A large employer might have dozens of plans across medical, dental, vision, life, disability, FSA, HSA, EAP, commuter benefits, legal plans, and more. Each has its own rules, its own edge cases, and its own interaction effects with the others.

Then there's the problem of change. Plans update annually, sometimes more often. Carrier formularies change quarterly. Regulatory requirements shift. An AI system that was accurate in January might give wrong answers in March if it hasn't ingested the latest formulary update or plan amendment.

Generic LLMs, even very good ones, don't understand the structure of a benefits ecosystem. They don't know how an accumulator interacts with a deductible, how a coordination of benefits clause works when both spouses have employer coverage, or how to navigate the difference between allowed amount, billed amount, and member responsibility. These aren't things you can solve with better prompting. They require purpose-built document parsing, domain-specific validation, and continuous monitoring against ground truth.

When you combine this technical complexity with ERISA's fiduciary framework, the risk profile of an internal build becomes clear. You're not just building software that might have bugs. Bugs can trigger personal legal liability for the plan sponsor and for the individuals responsible for plan administration who deployed it.

How working with a specialist vendor changes the equation

The plan sponsor is always the fiduciary. Working with a specialist vendor doesn't transfer that obligation. What it does is give you the documented diligence and operational rigor that satisfies ERISA's prudence standard, the same defense that protects plan sponsors who work with TPAs, PBMs, and carriers.

ERISA's prudence standard requires fiduciaries to act with the care and diligence of a knowledgeable person in similar circumstances. One of the recognized ways to meet that standard is to select a qualified expert, document your diligence process, and monitor the vendor on an ongoing basis.

This is the same pattern benefits teams already follow for every other critical vendor relationship. When a plan sponsor gets challenged on a decision, their defense is: "Here's our process. Here's how we evaluated options. Here's the expert we hired. Here's how we monitored them." That paper trail is what protects them.

You're still the fiduciary. But working with a specialist vendor converts 'we built it in-house and hope we got it right' into something benefits counsel will immediately recognize: a rigorous selection and monitoring process with a domain specialist. That's a defensible posture, and it's exactly what ERISA's duty of prudence contemplates.

Build it internally, and that defense gets much harder to construct. You're still responsible either way, but one path gives you a well-documented diligence process and the other leaves you explaining why your engineering team was qualified to interpret plan language at scale.

What I'd tell an engineering leader evaluating this decision

The technical challenge is solvable. I wouldn't be doing this work if I didn't believe that. But solving it requires a level of domain investment, specialized infrastructure, and ongoing validation that goes far beyond wiring up an LLM to a document store.

The ERISA dimension adds a layer that's entirely outside how most engineering teams think about risk. I'm not a lawyer, and I'm not trying to play one in this post. But I've spent enough time in the benefits world to know that the intersection of AI and fiduciary duty is a conversation you want to have with your legal and compliance teams before you greenlight an internal build, not after.

If you tell a good engineering team "don't build that, it's too complicated," you're risking someone thinking "challenge accepted." I get it. I've been that person. But the ERISA angle isn't about complexity. It's about a federal regulatory framework that assigns personal liability based on the functions your software performs, regardless of who built it or what they intended. That's not a risk you can engineer your way out of. It's a risk you mitigate by working with someone who's already built the domain expertise, accuracy infrastructure, and operational rigor around it.