Across many organizations, the people closest to AI systems are also the most aware of where those systems could go wrong. Engineers and data scientists often see biased training data, unexplainable model outputs, privacy gaps, or deployment choices that deserve a second look. Yet acknowledging these concerns inside a company remains surprisingly difficult. A recent analysis of AI ethics in the workplace, highlighted by HR Dive, argues that the problem is not a lack of technical knowledge: it is a workplace culture that quietly discourages people from raising red flags until something has already gone wrong.

The knowing-doing gap in AI ethics

Engineers are rarely confused about whether a model can produce discriminatory results or whether a dataset contains sensitive information. They can spot the difference between a robust test and a rushed launch. The gap is between what they know privately and what they feel safe saying publicly inside their organization. In meetings, concerns can be softened as just a thought or postponed indefinitely. In code review, ethical objections may be reduced to performance metrics, because that is the vocabulary rewarded by leadership.

This pattern creates a dangerous form of institutional silence. When the people with the deepest technical understanding do not speak, executives may believe a system is safer than it is. Risk registers remain incomplete, compliance teams investigate too late, and customers or employees eventually discover the harm. The AI system becomes not only a technical liability but a cultural one.

How workplace culture silences warnings

Several forces reinforce the silence. One is the perception that raising an ethical concern will be framed as a lack of commercial pragmatism. Engineers may fear being labeled as blockers, idealists, or people who do not understand business deadlines. In performance reviews, those who raise uncomfortable questions can be seen as less productive, especially if their warnings slow down a launch.

Another force is structural ambiguity. Many companies have no clear owner for AI ethics. Should a developer report a problem to their line manager, the legal team, the data protection officer, or an ethics board that does not exist? Without a visible and protected route, employees rationally choose silence. Even when policies exist, they often focus on compliance training rather than on day-to-day engineering decisions, so the gap between principle and practice remains wide.

Remote and hybrid work can make the problem worse. In distributed teams, there are fewer casual corridor conversations where someone might quietly say, “I am not comfortable with how this model is being used.” Written channels may be public, searchable, and intimidating. If a concern is raised in Slack, the entire team can see it, and the person who speaks up may feel exposed. The result is that ethical reflection stays private.

Building a speak-up culture for AI teams

Organizations that want to reduce AI risk need to treat internal dissent as a control, not an obstacle. That starts with leadership signals. Senior managers should ask engineers directly about what could go wrong, in private and in public, and then respond without defensiveness when the answer is inconvenient. A simple question such as “What is the worst realistic outcome of this release?” can open a conversation that a generic risk checklist cannot.

Clear escalation paths matter just as much. Companies should designate an AI ethics owner or review group, give it real authority, and make its role visible to technical staff. Reporting a concern should be possible without routing through an immediate manager, because not every manager will reward honesty. Anonymous channels can help, but they should not replace direct conversation. The goal is to normalize ethical objections as part of normal engineering work, not as an exceptional act of courage.

Finally, ethics should be embedded in the development process itself. Model cards, bias checks, data lineage reviews, and post-deployment monitoring should be as routine as unit tests. When these practices are part of the workflow, raising a concern becomes less personal—it is simply a defect report about a system, not a criticism of a colleague or a threat to a launch date. For remote and hybrid teams, having a structured digital channel to document concerns can help; tools such as XMF can support that documentation, but only if the culture treats the channel as safe and responsive.

Originally published by XMF, inspired by publicly reported industry news.