Amazon Nova reduces false refusals with rDPO

Since 6 July 2026, AWS has described how Amazon Nova uses Reverse Direct Preference Optimization, or rDPO, for selective “unlearning”. This is not about deleting knowledge. It is about reducing false refusals in approved moderation areas.

What AWS is changing

According to AWS, rDPO is the technique behind Customizable Content Moderation Settings for Amazon Nova. Approved customers can adjust safeguards across four responsible AI pillars: safety, sensitive content, fairness and security. The AWS documentation names Amazon Nova Lite and Pro and describes a combination of model alignment and a runtime output model.

The key point is operational. AWS says prompt engineering is not enough when a refusal pattern is embedded in model behaviour. rDPO is intended to reduce over-deflection while preserving capabilities such as instruction following, coding and mathematics. AWS also stresses that essential, non-configurable responsible-use controls remain in place.

Why this matters for enterprises

For CIOs and CDOs, moderation is becoming more than a binary model choice. The question is no longer only whether a model is safe or unsafe. The practical question is which business policy the organisation accepts, who approves it and how it is monitored in production.

That is especially relevant in regulated environments. The EU AI Act describes AI as a risk-based framework for providers and deployers. When model behaviour is adapted to use cases, companies need documented accountability: Who defines permitted content? Who reviews false refusals? Who assesses new risks? Who can roll back a change?

What DACH organisations should check now

Do not start with a broad approval for “less restrictive” models. Start with one specific process where false refusals create measurable friction: customer service, internal knowledge search, technical documentation or moderation of specialist content.

Privacy, business owners, security and operations should then define which moderation change is acceptable, which test cases prove it and which logs must be available for audit. The guiding question is simple: are you solving a clearly bounded business problem — or creating a hard-to-explain exception in model behaviour?