8.0
热点
AI SCORE
技术实践2026-08-24 22:00
企业 AI 负责任落地需要从开发者工作流设计入手
Stack Overflow Blog#AI治理#开发者工作流#最佳实践
Editor brief · 编辑速览
企业无法靠一份政策文档解决影子 AI 问题，需要让负责任的 AI 使用方式比即兴使用更容易。作者强调工作流设计是 AI 治理的核心杠杆。
[Ed. note: If you listened to a podcast or read an article of ours and want to publish a response, let us know. We're open to highlighting community views that respond to our work in ways that don't fit in a comment section, whether you agree or disagree. Reach out at pitches@stackoverflow.com.]
The fastest way to create shadow AI is to publish a policy and assume behavior will follow. Developers work under delivery pressure, face ambiguous problems, and reach for tools that help them move. When the approved path feels slow, vague, or disconnected from actual engineering work, people create a faster path for themselves.
That tension sits at the center of responsible AI adoption. In Ryan Donovan's recent conversation with Microsoft's Sarah Bird on the Stack Overflow podcast, responsibility centered on impact, accountability, and thoughtful human-AI workflow design. Stack Overflow's developer AI adoption and trust findings show why this operational focus matters: 84% of respondents use or plan to use AI tools, while more developers distrust AI accuracy than trust it. The leading frustration involves outputs that look almost right but require extra debugging.
Organizations cannot solve that gap with a document employees read once. They need to make responsible use easier than improvised use.
Leaders often describe unapproved AI use as a compliance problem. That diagnosis starts too late. By the time an engineer pastes sensitive material into a public model or quietly installs an unapproved coding assistant, the organization has already failed to provide a credible route for getting the work done.
Microsoft's Work Trend Index found widespread shadow AI through bring-your-own tools, with many users reluctant to admit that they apply AI to important tasks. That behavior does not automatically indicate recklessness. It often reflects a practical calculation: the sanctioned process offers less value than the unsanctioned shortcut.
The right response starts with curiosity. Which tasks drive developers toward outside tools? What friction blocks the approved option? Which data, context, integrations, or permissions do teams need? A Stack Overflow discussion of monitored gateways and approved AI platforms shows the value of channeling experimentation through infrastructure that supports visibility instead of trying to suppress it through blanket prohibition.
When leaders treat every unapproved use as misconduct, developers learn to hide experimentation. When leaders treat it as diagnostic evidence, they can improve the system.
Good policy defines intent. Good operations translate that intent into decisions a developer can make during ordinary work.
The NIST framework organizes AI risk management around four functions: Govern, Map, Measure, and Manage. Those verbs imply ongoing work. Governance should tell a team how to classify a use case, which model and data sources it may use, how to test the result, who owns approval, and what evidence belongs in the development record.
A practical policy should answer questions such as these without forcing an engineer to schedule a meeting with a committee:
Developers rank security and privacy concerns as the leading reasons to reject a technology, according to Stack Overflow's technology adoption findings. Clear operational rules therefore support adoption rather than obstruct it. They reduce uncertainty about what responsible use looks like.
A policy stored in a learning portal competes poorly with an AI assistant embedded in an IDE. Controls need to live in repositories, pull requests, build pipelines, access systems, and deployment workflows.
NIST's secure AI development guidance extends secure software practices across the development lifecycle. The same principle should govern enterprise AI use. Teams can place approved model configurations in version control, restrict access by role, scan prompts and outputs for secrets, preserve logs for higher-risk use cases, and require tests before AI-generated changes merge.
GitHub's guidance on human oversight for AI-generated code recommends functional checks, context verification, dependency review, collaborative review, and automation where appropriate. This turns the abstract instruction to "review AI output" into a repeatable engineering process.
The controls should also match AI-specific failure modes. The OWASP risks for generative AI applications include prompt injection, sensitive information disclosure, supply-chain weaknesses, improper output handling, and excessive agency. A team that uses an AI tool to explain code faces a different risk profile from a team that gives an agent write access to production systems. Applying the same approval burden to both creates delay without improving safety.
Responsibility becomes blurry when people describe AI as a collaborator, assistant, or agent. The vocabulary sounds useful, but software cannot accept organizational accountability.
Every use case needs a named human owner who understands the intended outcome and has enough authority to stop or change the process. That person does not need to inspect every token. The owner must define acceptable performance, determine where human judgment enters, and make sure someone responds when the system fails.
The NIST Generative AI Profile for trustworthy deployment emphasizes risk management throughout design, development, use, and evaluation. In practice, ownership should follow that lifecycle. Product leaders own the business decision. Engineering leaders own implementation quality. Security and privacy specialists define relevant controls. Developers own the code they submit. Reviewers own the decision to approve it. Operators own production monitoring and incident response.
This division prevents a familiar failure pattern: everyone touches the AI system, yet nobody owns its consequences.
Teams cannot manage risks they feel unsafe reporting. A developer who notices that an approved tool leaks context, fabricates dependencies, or encourages insecure code needs a credible way to raise the issue without being treated as resistant to innovation.
Google's Project Aristotle identified psychological safety as the most important dynamic in its study of effective teams. Google describes it as a climate where people can take interpersonal risks, ask questions, and surface mistakes. That climate matters directly for AI because many failures first appear as weak signals: an odd completion, a suspicious package, an undocumented data path, or a result that seems plausible but conflicts with domain knowledge.
DORA research also connects psychologically safe software delivery cultures with stronger performance and resilience. Leaders undermine that advantage when they celebrate adoption numbers while punishing people who question the tools.
Managers should ask teams what went wrong, where the workflow encouraged the mistake, and which safeguard would help next time. They should avoid asking why a particular developer "trusted the AI." That framing personalizes a system failure and teaches everyone else to stay quiet.
A generic AI awareness session sits too far from the choices developers make under pressure. Stack Overflow's developer trust analysis frames effective use as a skill that includes structuring prompts, evaluating outputs, and integrating generated code into existing systems.
Effective AI training for enterprise teams should resemble a license to operate. It should cover the approved tools, permitted data, common failure modes, review expectations, escalation route, and concrete examples from the organization's own technology environment.
A backend engineer needs practice checking generated database migrations, authentication logic, and dependency choices. A data engineer needs practice protecting sensitive records and validating transformations. An engineering manager needs to know when a pilot requires security, legal, or architecture review. A platform team needs to know how to observe agent behavior and constrain permissions.
Stack Overflow's developer learning patterns for AI tools show that developers actively build AI skills through multiple resources, including AI-enabled tools themselves. Organizations should use that existing appetite. Give teams sandboxed exercises, flawed outputs to review, examples of acceptable prompts, and internal patterns they can reuse.
Training should produce artifacts inside the workflow: repository instructions, review checklists, reusable test suites, approved prompt patterns, and documented examples. A certificate proves attendance. These artifacts shape behavior.
Leaders often measure AI adoption through licenses assigned, prompts submitted, or weekly active users. Those metrics reveal activity, but they say little about engineering value or responsible use.
The 2024 DORA research found that higher AI adoption correlated with improvements in documentation quality, code quality, and review speed, while also identifying possible negative effects on software delivery performance. Those mixed effects of AI on development performance support a more disciplined measurement approach.
Teams should evaluate a defined workflow before and after introducing AI. Useful measures may include cycle time, escaped defects, rollback rate, security findings, review burden, documentation quality, incident volume, developer satisfaction, and time spent correcting AI output. The relevant measures depend on the task and the risk.
Stack Overflow's survey also found that agents indicate gains in individual productivity but not team collaboration. That difference matters. An engineer may complete a local task faster while shifting verification, integration, or maintenance work onto colleagues. Responsible measurement follows the work across the team instead of stopping at the first apparent gain.
Developers will use AI when it helps them solve real problems. Governance succeeds when it makes that use visible, testable, and supportable.
The organization should provide approved tools with useful context, straightforward access, clear limits, and fast escalation. It should encode workflow design for people and agents in repositories and automated checks. It should require more review as data sensitivity, autonomy, reach, and reversibility increase. It should protect people who report failures. It should measure team outcomes rather than count clicks.
Tool vendors make the same point in their own guidance. GitHub tells users to treat Copilot as a tool rather than a replacement and to review and validate generated responses. CISA's secure-by-design principles similarly call for organizations to build responsibility into product design instead of transferring the full burden to end users.
The central lesson is simple. Responsible AI depends less on whether an organization has a policy than on whether its daily system of work makes responsible behavior practical. Leaders who want durable AI adoption at work should design the approved path so developers can move quickly without surrendering judgment, accountability, or engineering discipline.
Dr. Gleb Tsipursky, a behavioral scientist called the "Office Whisperer" by The New York Times, helps tech-forward leaders stop overpaying for AI while boosting engagement and innovation. He serves as the CEO of the AI consultancy Disaster Avoidance Experts, and wrote eight books, including The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026).