Michael D.
Goggans

One of the questions I keep returning to, both in my legal, HR, and compliance work and in my coursework at LSE, is what accountability actually means when AI influences a decision that affects a person.

The easy answer is that the human remains accountable. The model is just a tool. The lawyer, HR director, manager, or compliance lead makes the decision. The human signs off.

That answer is comforting, but it does not fully survive contact with how these systems are actually used.

When an AI tool drafts a contract clause, screens a candidate, summarizes a policy, or flags a compliance issue, it is not neutral. It shapes what the human sees. It narrows what they consider. It influences what they are likely to conclude. The human may still make the final call. But the decision has been meaningfully shaped by a system they did not build, cannot fully inspect, and may not be able to reproduce later.

That does not mean we should avoid AI. We rely on complex tools all the time. But it does mean the governance model has to change to account for that influence.

A few principles keep surfacing:

Accountability has to follow influence, not just authorship.

If AI materially shaped the decision, the governance structure has to account for that, even when a human formally made the call. Otherwise, "human in the loop" becomes more of a liability shield than a meaningful control.

Explainability cannot be bolted on at the end.

If no one can explain why the system produced a given output, no one can meaningfully review it. Explainability has to be designed into the workflow, not reconstructed after a challenge, complaint, audit, or regulator inquiry.

Documentation is a critical audit trail.

What was the prompt? What context was provided? What model or system version was used? What did the human accept, reject, or change before acting?

Without that record, an organization may know that a human approved the decision, but not how the decision was actually formed.

The hardest cases are not always the obvious ones.

Everyone understands that AI should not make termination decisions unsupervised. The more difficult questions are the dozens of smaller AI-influenced choices that shape a process over time. Each one may be defensible in isolation. Cumulatively, they may become something else.

I do not think legal, HR, and compliance teams have settled answers here yet. Many frameworks are either too restrictive to be operationally useful or too permissive to be defensible.

The real work is in the middle: building controls that are practical enough to be used, but strong enough to hold up when the decision is later questioned.

If you are working through this inside your own organization, I would be interested to compare notes on what is actually holding up in practice.

A quiet truth about compliance work: the most elegant policy is rarely the one the organization can effectively comply with. I have seen beautifully drafted policies fail because they assumed perfect behavior, perfect data, or perfect timing.

Real organizations do not operate that way.

The best legal, HR, and compliance systems I have seen are designed with friction in mind. Human error. Delay. Ambiguity. Edge cases. Conflicting priorities. Systems that do not quite talk to each other. These are operational realities. Better policies do not just ask, “Is this compliant?” They ask, “Can this survive the actual work?”

That distinction matters more as organizations scale and operate across jurisdictions. What looks beautiful on paper, ticking every box a customer might ask about, often breaks the moment it hits a different regulatory environment, a manager under pressure, a missed approval, or a system default nobody checked.

I have come to think of this as the difference between policy and the organization’s operating system.

Policy describes what should happen. The operating system is what actually happens when the policy meets a Wednesday afternoon, a contractor who started before the paperwork was finished, or a tool that routes approval to someone who is out of office.

The gap between those two things is where much of the real compliance risk lives. Not in the absence of rules, but in the distance between the rules and the work.

The strongest compliance functions I have seen treat that gap as their primary territory. They write policies that can be effectively executed. They build controls that survive bad days. They assume the system will be stressed and design accordingly.

Compliance that ignores real-life operations eventually just becomes theater.

What policies have you seen that looked perfect but quietly failed?

I've been on LinkedIn for a long time and rarely posted. That’s probably going to change.

For context: I’m Chief Legal Officer and head of HR and other departments at Cennox, operating across the US, UK, and EU. The role sits at the intersection of legal, HR, compliance, and operations, which in practice means dealing with problems that don’t belong neatly to any one function.

Before this, I spent a couple decades across legal roles (ADA, General Counsel, litigation, municipal, corporate), plus teaching IP, Corporate and Cybersecurity law as an adjunct professor at Seton Hall. Useful background, but most of what matters now looks very different from how any of that was originally taught.

Lately, a good deal of my time is spent analyzing and implementing AI and other technology solutions inside legal and HR workflows.

Not just evaluating it. Not just talking about it at a high level. Investigating, building, and deploying it in environments where the margin for error is low and the accountability doesn’t go away just because a model was involved.

The interesting problems aren’t the ones you see in headlines. They’re much more operational:

• Who is accountable for an AI-assisted decision?
• How do you make outputs explainable enough to rely on?
• Where do you add controls including confidentiality and security without breaking usefulness?
• What does “good” even look like when the system isn’t deterministic?

Legal and HR teams are being asked to adopt these tools while also owning the risk they introduce. That tension isn’t theoretical, it shows up immediately when you try to put anything into production.

I don’t have clean answers. I’m not sure anyone does yet.

But working through this, finding what actually works, what fails, and what doesn’t translate from theory to practice, seems more useful than another overly polished take on “AI transformation.”

I’m also currently working through a second LL.M. at LSE, which has been a helpful forcing function to think more systematically about some of this.

I’ll share observations here as I can. Mostly where law, HR, and operations collide, and what it looks like to make decisions in that space with imperfect information.

If you’re dealing with similar problems, I’d be interested in comparing notes.

I’ve been spending a lot of time thinking about the intersection of technology and governance. How is technology reshaping legal, HR, and compliance systems in ways that are not always obvious at first?

Over the past few years I have noticed something interesting in conversations about technology. Most discussions focus on what new systems can do. Far fewer focus on what those systems change about responsibility, governance, and decision making.

That gap matters most in environments like law, HR, risk, and compliance. In those areas technology is not just a productivity tool. It becomes part of how decisions affecting people and organizations are made.

In many companies today policies are still written by lawyers. Processes are managed by HR or Operations. But the behavior of the system is defined by software in which the lawyers, HR staff and Operations team never had input, often regardless of how the policy is drafted or taught. Technology and its architecture has become a driving factor in governance. It is what Lessing called “Code as Law” and it dominates our world in ways many do not appreciate.

Here, I will share a few observations on this topic and others from time to time.