<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Responsible AI on carney.wiki</title><link>https://carney.wiki/tags/responsible-ai/</link><description>Recent content in Responsible AI on carney.wiki</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Tue, 20 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://carney.wiki/tags/responsible-ai/index.xml" rel="self" type="application/rss+xml"/><item><title>AI Risk Is a Business Risk, Not Just a Technical One</title><link>https://carney.wiki/blog/ai-risk-is-a-business-risk-not-just-a-technical-one/</link><pubDate>Tue, 20 Jan 2026 00:00:00 +0000</pubDate><guid>https://carney.wiki/blog/ai-risk-is-a-business-risk-not-just-a-technical-one/</guid><description>AI risk is business risk.
That sounds obvious until you look at how most companies still manage it.
Too often, AI risk gets pushed into the technical corner. The security team worries about exposure. The data team worries about model performance. Legal gets pulled in late. The board gets a sanitized update after the pilot has already become operational.
That is backwards.
If an AI system influences customers, employees, financial outcomes, operational decisions, or regulated processes, the risk is not contained inside the model.</description></item><item><title>Building AI Guardrails Without Killing Innovation</title><link>https://carney.wiki/blog/building-ai-guardrails-without-killing-innovation/</link><pubDate>Mon, 15 Dec 2025 00:00:00 +0000</pubDate><guid>https://carney.wiki/blog/building-ai-guardrails-without-killing-innovation/</guid><description>AI governance should not be a moat around innovation.
It should be the road.
That distinction matters because a lot of companies are about to overcorrect. They see real AI risk, then respond with broad restrictions, vague policies, and approval processes that make practical teams route around the system.
That does not create safety.
It creates shadow AI.
The better path is guardrails, not gates. Give teams enough structure to move quickly inside known boundaries, and reserve heavier review for use cases that can materially affect customers, employees, money, safety, compliance, or trust.</description></item><item><title>What Boards Need to Know About AI Risk</title><link>https://carney.wiki/blog/what-boards-need-to-know-about-ai-risk/</link><pubDate>Sun, 02 Nov 2025 00:00:00 +0000</pubDate><guid>https://carney.wiki/blog/what-boards-need-to-know-about-ai-risk/</guid><description>Boards do not need to understand every AI model.
They do need to understand where AI creates business risk.
That is the important distinction.
AI is moving into customer interactions, employee workflows, software development, analytics, content production, fraud detection, security operations, and decision support. Some systems are low risk. Some can materially affect customers, employees, revenue, compliance, or reputation.
Board oversight should focus on the second group.
The question is not &amp;ldquo;Can the board explain how the model works?</description></item></channel></rss>