DORA | Capabilities: Clear and communicated AI stance<br>AI<br>Research<br>Capabilities<br>Guides<br>Insights<br>Quick Check<br>Search<br>Community open_in_new
Download the ROI of AI-assisted Software Development report.<br>Capabilities<br>Clear and communicated AI stance<br>AI<br>The cost of ambiguity<br>Ambiguity stifles innovation and safety. Without clear guidance, organizations face two equally detrimental extremes: developers acting too conservatively out of fear they will cross an invisible line, or acting too permissively and using unvetted tools that introduce significant risk.<br>A clear and communicated AI stance acts as a corrective to this uncertainty. It is not merely a legal document buried in a wiki; it is a comprehensible, widely socialized framework that tells developers: “Here is how we expect you to use AI, here are the tools you can use, and here is how we support you.”<br>DORA research shows that this capability is a powerful amplifier. When an organization’s stance is clear and well-communicated, it amplifies the positive impact of AI on individual effectiveness, organizational performance, and software delivery throughput. Perhaps most importantly, it turns AI from a source of anxiety into a tool for reducing friction.<br>DORA research found with a high degree of certainty that a clear and communicated AI stance amplifies AI’s positive influence on individual effectiveness and organizational performance . Furthermore, it takes the neutral effect AI often has on friction and turns it into a beneficial decrease in friction.
The AI Angle: Psychological safety as an enabler<br>Ambiguity stifles adoption. If a developer isn’t sure whether using a coding assistant will get them fired or sued, they will likely either hide their usage (shadow AI) or avoid the technology entirely.<br>A clear stance provides the psychological safety needed for effective experimentation. It shifts the cognitive load from “Am I allowed to do this?” to “How can I use this to solve my problem?” By defining practical guardrails—such as which data classification levels are appropriate for which tools—organizations empower teams to innovate within safe boundaries.<br>Research indicates that a successful stance is defined by four key perceptions among developers:<br>Expectation: Does it feel like using AI is expected?<br>Support: Does the organization support experimentation?<br>Permission: Is it clear which tools are permitted?<br>Applicability: Does the policy apply specifically to my role?<br>How to implement a clear AI stance<br>Building a clear stance is a journey that moves from executive vision to daily workflows. It requires a cross-functional effort to balance risk management with developer reality.<br>Secure executive sponsorship<br>Clarity starts at the top. Leadership must define and champion a clear AI mission and adoption plan. This signals strategic importance and provides the authority necessary to enact a comprehensive policy across the organization.<br>Form a cross-functional working group<br>A policy created solely by the legal or security department is unlikely to survive contact with reality. Author your stance using a working group that includes representatives from engineering, legal, security, IT, and product leadership. This group is uniquely positioned to balance risk with utility.<br>Adopt a “three-bucket” framework<br>Avoid a binary “yes/no” policy. Instead, categorize tools and use cases into three clear buckets:<br>Prohibited: High-risk uses that are never allowed (e.g., pasting customer PII into a public chatbot).<br>Permitted with guardrails: Allowed only with specific controls (e.g., using proprietary code with an enterprise-grade, approved tool).<br>Allowed: Low-risk, high-value activities that are actively encouraged (e.g., generating boilerplate code or brainstorming ideas without proprietary data).<br>Publish as a “living document”<br>Don’t lock your policy in a static PDF. Publish it as a living document in a central, searchable developer hub. This hub should host the official list of approved tools, the policy itself, and an evolving FAQ.<br>Socialize and establish feedback loops<br>A policy is useless if no one knows it exists. Launch it through “town halls” and team meetings. Crucially, establish a feedback loop where developers can ask questions or suggest new tools. This allows the policy to evolve alongside the rapid pace of AI technology.<br>Common pitfalls<br>The “one-time” policy: Treating the stance as a static document. AI technology changes monthly; your policy must be reviewed and updated regularly based on lessons learned.<br>The “whiplash” effect: Changing the policy too frequently without giving teams time to adapt. Constant changes can be worse than no policy at all.<br>Myopic authorship: Allowing a single department (like Legal or Security) to dictate terms without Engineering input creates a stance that ignores the practical realities of software development.<br>Why...