Best Practices for Organizations

This article is part of my series on AI safety and governance. If you haven't read the pillar article, I'd start there for context on how this fits into the broader picture.

Why I Wanted to Move From Concepts to Practice

A lot of this series has been about ideas: alignment, governance frameworks, risk assessment, explainability. I think those ideas matter, but I've also noticed that when I talk to people working inside organizations, the question that comes up most often is much more concrete: okay, but what do we actually do?

This article is my attempt to answer that. I want to lay out the practices I think separate organizations that are genuinely building AI responsibly from those that are mostly talking about it. I'll say upfront that I don't think any of these practices are silver bullets on their own. What I think matters is how they fit together.

Documentation Standards

I keep coming back to documentation throughout this series, and I think that's because it's genuinely foundational. Without documentation, I don't think any of the other practices I'll describe actually function, because there's nothing to review, audit, or build on.

I think good documentation in this context covers a few things. It covers what a system is, what it was trained on, and what its intended uses are. It covers what testing was done, including the kind of risk assessment and red-teaming I discussed in earlier articles. It covers known limitations, the things a system isn't good at, the situations where it's more likely to fail, the populations or use cases where it hasn't been adequately tested. And it covers decisions: not just what the test results were, but what was decided as a result, and who made that call.

I think the last one is the piece organizations most often skip, and I think it's also the piece that matters most when something goes wrong later. A test result without a documented decision tells you what was found. A documented decision tells you what the organization actually did about it, which I think is the more important thing from a governance standpoint.

Internal Review Processes

I've found that the organizations I'd describe as taking this seriously tend to have some kind of internal review process that sits between "the team building a system thinks it's ready" and "the system actually ships." I think the value of this isn't just catching problems, though that matters too. I think the value is also in creating a structural moment where someone outside the immediate development team is required to ask hard questions.

I think the composition of this review matters. If it's made up entirely of people with the same incentives as the development team, namely, getting the system shipped, I don't think it functions as a meaningful check, even if it exists on paper. I've seen more value in review processes that include people whose role is explicitly to represent considerations the development team might not be incentivized to weigh as heavily: safety, ethics, legal exposure, user trust.

I also think the timing of review matters. A review that happens right before launch, when there's enormous pressure to ship and limited time to act on findings, tends to function very differently than a review that happens early enough that findings can actually change the direction of a project. I think the earlier reviews tend to be more honest, partly because there's less sunk cost on the table.

Staged Rollouts

I think one of the most practically useful ideas I've encountered in this space is the staged rollout: rather than deploying a system to everyone at once, deploying it first to a smaller group, learning from that, and expanding gradually.

What I like about this approach is that it treats deployment itself as part of the testing process, rather than as the end of it. I discussed in my article on risk assessment how real-world usage often surfaces things that pre-deployment testing doesn't, and I think staged rollouts are one of the most direct ways of acting on that insight. If something concerning shows up with a smaller group of users, the consequences are contained, and there's an opportunity to address it before a much larger group is affected.

I think the trade-off here is obvious: staged rollouts are slower, and there's often commercial pressure to move faster. But I think organizations that skip this step are, in effect, choosing to do their real-world testing on their full user base from day one, whether or not they think of it that way.

Feedback Loops That Actually Get Acted On

I think this is the practice that's easiest to claim and hardest to actually do well. Almost every organization I've looked at has some mechanism for collecting feedback: user reports, internal monitoring, external research, red-teaming findings. What I think varies enormously is whether that feedback actually changes anything.

I've come to think of a feedback loop as having a few necessary pieces. There needs to be a way for issues to be surfaced in the first place, which sounds obvious but isn't always true, especially for issues that are subtle or that affect a small fraction of users. There needs to be a process for triaging what comes in, since not everything can be acted on immediately and some prioritization is inevitable. And there needs to be a mechanism for findings to actually reach the people who can do something about them, with enough authority and resources to act.

I think the failure mode I've seen most often isn't that organizations don't collect feedback. It's that feedback gets collected and then sits somewhere, reviewed by people who don't have the ability to act on it, while the people who could act on it never see it. I think a feedback loop that doesn't close, where information doesn't make it back to a point of actual decision-making, isn't really a loop at all.

How These Practices Reinforce Each Other

I think the reason I wanted to present these together, rather than as a checklist of separate items, is that I've come to see them as mutually reinforcing in ways that matter.

Documentation makes review possible, because reviewers need something concrete to evaluate. Review processes are what create the occasions where documentation actually gets used, rather than just produced and filed away. Staged rollouts generate the real-world information that feedback loops are meant to capture. And feedback loops, when they work, generate the kind of findings that should feed back into documentation and future reviews, closing the cycle.

I think when one of these pieces is missing, the others tend to become less effective too. Documentation without review becomes a formality. Review without good documentation becomes guesswork. Staged rollouts without functioning feedback loops don't actually provide the learning they're supposed to provide. I think this is part of why I find it unhelpful when these practices get treated as independent boxes to check, because in my experience, they only really work as a system.

What I Think This Looks Like From the Outside

I want to end with a slightly different angle: how do you tell, from outside an organization, whether these practices are actually in place, versus just claimed?

I'll be honest that I think this is hard, and I don't think there's a foolproof signal. But I've found a few things worth paying attention to. Organizations that can speak concretely about what they've found through testing, including things that didn't go well, tend to strike me as more credible than ones that only speak in generalities about their commitment to safety. Organizations that have made changes to products or timelines based on internal findings, especially changes that were costly or unpopular, are demonstrating that their feedback loops actually close. And organizations that engage with external scrutiny, rather than treating it purely as a public relations challenge, tend to be the ones I trust more when it comes to claims about responsible development.

I think this connects back to a theme that's run through this whole series: responsible AI development isn't a state an organization arrives at and then maintains effortlessly. It's an ongoing set of practices that have to be sustained, especially under the kind of commercial and competitive pressure that I think characterizes this industry right now. If you're building out these practices internally, I think the natural next step is to look at how they get formalized into something like an AI ethics board, which is what I cover in the final, most operational piece of this series.