Six Guidelines for Keeping Humans in the Loop: What IEEE’s Latest AI Governance Piece Gets Right

For years, the loudest voices in AI governance came from regulators, ethicists, and policy shops. The people actually shipping models into production were often an afterthought, consulted late and asked to bolt compliance onto systems already built. That is starting to change. A growing share of the governance playbook is now being written by practitioners, and a recent IEEE Spectrum piece by Sravan Vadigepalli, an IEEE senior member and technology executive at Lowe’s Companies, Inc., is a useful example of the shift.

Vadigepalli leads enterprise AI strategy, AI products, and partnerships at Lowe’s, a role that puts him close to the messy reality of deploying AI inside a large organization. His article, “6 Guidelines for Governing AI,” argues that governance should start from a single organizing principle: build AI systems that keep humans in the loop. For engineers, that framing matters more than it might first appear.

Who Is Writing, and Why It Matters

Governance frameworks written by academics tend to describe what ideal systems should do. Governance frameworks written by executives tend to describe what organizations can actually enforce. Vadigepalli sits in an unusual position between the two. His IEEE senior membership signals engagement with the technical community, while his day job at Lowe’s involves deciding which AI products get built, how they get evaluated, and who is accountable when they misbehave.

That dual vantage point is worth noting because it reflects a broader trend. The people closest to production systems are increasingly the ones codifying the rules. This is the same dynamic showing up in hiring data, where roles like the Forward Deployed Engineer: The AI Job Title That Grew 5,230% in 15 Months illustrate how much demand now exists for engineers who sit between a model and the customer. Governance is following the same path, moving from the policy office into the engineering org.

The Six Guidelines at a Glance

The article proposes six guidelines for governing AI development and deployment, framed around the human-in-the-loop principle. The available source material includes only the article’s title, subtitle, author, and bio, so the guideline text itself is not reproduced here. The available source material does not include the guideline text, so the structure and intent cannot be characterized here. Because the guideline text is not available here, the specific recommendations cannot be summarized; readers should consult the original IEEE Spectrum article.

Whether this framing is representative of practitioner-led governance more broadly is not something the available source material can establish.

Human-in-the-Loop in Practice

“Keeping humans in the loop” is one of those phrases that sounds obvious until you try to implement it. In practice, it means different things at different stages.

At design time, it means deciding which decisions the system is allowed to make autonomously and which require a person. A recommendation engine that surfaces products is low stakes. A system that approves credit or denies a claim is not. The design decision is where the loop is first drawn.

At deployment time, it means review gates. These can be formal, such as a sign-off before a model reaches production, or embedded, such as a staging environment where a human evaluates outputs against a rubric before promotion. The key property is that the gate is real: someone can say no, and that no sticks.

At monitoring time, it means escalation paths and override mechanisms. A human needs a way to intervene when the system behaves unexpectedly, and that intervention needs to be logged. This is where the loop often breaks down in practice. Research from Hugging Face, as covered in the linked InferenceWeekly piece, argues that many oversight mechanisms are designed in ways that actively discourage human participation, turning the loop into a rubber stamp. That finding is a useful counterweight to any governance framework that assumes a human in the loop is automatically a safety feature.

From Guidelines to Engineering Artifacts

The most valuable contribution of a practitioner-authored framework is that it can be translated into artifacts engineers already produce. Governance principles become concrete when they attach to things like:

• Code reviews: A reviewer checks not just correctness but whether the system’s human oversight points are intact.
• Model cards: Documentation that records intended use, limitations, and the human decision points the system depends on.
• Audit logs: Immutable records of when a human intervened, what they saw, and what they decided.
• Deployment checklists: A pre-launch list that includes oversight verification alongside performance and security checks.

This is where the gap between academic principles and production systems usually shows up. A principle like “ensure meaningful human oversight” is hard to test. A checklist item like “confirm that the override path is reachable within the system’s response budget” is testable. Frameworks that make this translation explicit are more likely to survive contact with a real engineering org.

Limits and Open Questions

No six-point framework resolves everything, and it is worth being honest about where this approach leaves gaps.

Enforcement. Guidelines are not law. Without a mechanism to require compliance, adoption depends on organizational will. A team under deadline pressure may treat oversight as optional.

Accountability. Naming an owner is easier than giving that owner the authority and resources to act. Governance without budget is a document, not a control.

Cross-jurisdictional compliance. AI rules differ by region, and a framework written for one enterprise context may not map cleanly onto another. Teams operating internationally need to reconcile multiple regimes, and a single set of guidelines rarely does that work.

Latency and oversight tension. Human review takes time. In systems where speed is the product, inserting a human can degrade the experience enough that teams route around the gate. This is the central unresolved tension in human-in-the-loop design, and it is not solved by declaring that humans must stay in the loop.

Measurement. It remains hard to verify that oversight is meaningful rather than theatrical. Without metrics for oversight quality, organizations can claim compliance while the loop is effectively empty.

What Teams Should Adopt First

The most useful takeaway from practitioner-authored governance is not the specific list but the direction of travel. Frameworks written by people who deploy AI are becoming the bridge between regulation and shipping, because they speak the language of both.

For teams deciding where to start, the highest-leverage move is usually the least glamorous: write down the human decision points in your system, name an owner for each, and log every intervention. That single practice turns an abstract principle into an auditable artifact. From there, review gates and model cards follow naturally.

The six guidelines are a starting point, not an endpoint. The work of keeping humans meaningfully in the loop is ongoing, and it belongs to the engineers who build the systems, not only to the regulators who write about them.

We covered human loop broken hugging in more detail elsewhere.

We covered governance stage weave compliance in more detail elsewhere.