<?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 |</title><link>https://sanaamironov.com/tags/responsible-ai/</link><atom:link href="https://sanaamironov.com/tags/responsible-ai/index.xml" rel="self" type="application/rss+xml"/><description>Responsible AI</description><generator>HugoBlox Kit (https://hugoblox.com)</generator><language>en</language><lastBuildDate>Sat, 23 May 2026 00:00:00 +0000</lastBuildDate><image><url>https://sanaamironov.com/media/sharing.png</url><title>Responsible AI</title><link>https://sanaamironov.com/tags/responsible-ai/</link></image><item><title>AI Governance as Engineering Work</title><link>https://sanaamironov.com/blog/ai-governance-as-engineering-work/</link><pubDate>Sat, 23 May 2026 00:00:00 +0000</pubDate><guid>https://sanaamironov.com/blog/ai-governance-as-engineering-work/</guid><description>&lt;p&gt;AI governance is often described as policy, oversight, or compliance. Those pieces matter, but governance also has to become engineering work.&lt;/p&gt;
&lt;p&gt;A useful governance process should connect risks to artifacts: model behavior, data quality, system boundaries, logs, prompts, tests, permissions, and human review paths. Without those artifacts, governance becomes a document rather than an operating practice.&lt;/p&gt;
&lt;p&gt;My current interest is in risk mapping that gives teams practical ways to ask better questions: what could fail, what evidence would reveal it, and what controls can reduce the risk before deployment?&lt;/p&gt;</description></item></channel></rss>