Expert Interview, June 2026
Trustworthy AI
Kill Switches, Observability and Separate Authentication
Bogdan Grigorescu is Senior Technical Lead at Direct Line Group. At The AI Summit London, he spoke on the panel: Observability | Ensuring Trust, Control, and Reliability at Scale. In this interview, he discusses AI threat scenarios, why authentication must remain deterministic and separate from chat interfaces, the case for circuit breakers in AI systems, how frameworks like DORA and the GDPR apply, and why observability and fail safes beat attempts to enforce policy as code on non deterministic systems.

Read the Full Interview
Bogdan: I’m Bogdan Grigorescu, Senior Technical Lead at Direct Line Group. I’m responsible for shared services engineering, automation and customer experience on our contact centre as a service platform.
Interviewer: What are some of the top production AI threat scenarios, and how do you prioritise them?
Bogdan: Many are well documented by security practitioners, but one scenario deserves urgent attention because of its impact. Recently, a Meta GPT‑JI bot was hijacked via prompt injection, resulting in account takeovers of high‑profile Instagram users. You might ask, “Doesn’t two‑factor authentication prevent this?” It should—but the attack effectively performed social engineering on a machine. The attacker told the bot they couldn’t access the email address receiving one‑time codes and requested the code be sent to a different address. After several prompts, the bot accepted the new email for code delivery. The attacker received the two‑factor code, changed the password and took over the account. This happened to several dozen high‑value accounts, including high‑net‑worth individuals and major influencers.
The attack vector—account takeover—is not new. The lesson is. It’s a bad idea to put a general‑purpose chatbot in front of authentication flows. If you must have a chatbot at the front door, keep authentication completely separate and deterministic. Do not embed authentication logic in or behind the chat interface. Segregate it, with its own hardened workflow. This is a high‑impact, low‑cost attack that’s fast to execute and open to anyone on the internet. I’d prioritise this risk immediately and for the foreseeable future.
Interviewer: To summarise the solution: keep the chat interface separate from authentication?
Bogdan: Exactly. You can hand a user over from a chatbot to an authentication flow, but authentication must be handled entirely separately, including failure handling. Maintain a distinct, deterministic authentication layer and a separate chatbot flow.
Interviewer: How do you secure the AI supply chain—data, training and third‑party models—against tampering and unauthorised access?
Bogdan: It’s a vast topic, but there’s one control I believe should be mandated: a circuit breaker, or kill switch, designed into any AI system—not just chatbots. Think of industrial safety: when something goes wrong, an authorised person hits a button and everything stops to limit damage. Today there’s no broad requirement for this, and very few systems implement it.
This should become a pillar of safety and governance—covering information security and, where relevant, physical safety when AI interacts with the real world. The kill switch must be triggered through a simple, separate, rock‑solid workflow, and it must be tested regularly—like a fire drill. Test unannounced, at least annually (ideally more often), to verify you can decouple and halt an AI system involved in critical workflows. It validates both the mechanism and the people and processes around it, accounting for staff turnover and role changes. Training doesn’t need to be heavy—akin to fire safety training—but it must be consistent.
Interviewer: What governance checkpoints are mandatory to deploy models into production, and what ongoing checks keep them fit for clients?
Bogdan: It depends on your regulatory context. Highly regulated sectors differ from lightly regulated or unregulated ones, so there’s no single checklist for all. In the UK and EU context, consider frameworks like the Digital Operational Resilience Act (DORA) for operational resilience and, of course, the GDPR for data protection. You need appropriate metrics—mean time between failures, change failure rates, recovery times—and clarity on supplier dependencies and lock‑in, especially for critical workflows.
Equally important is role clarity around data controllership and processing. All of this applies to AI, but you must build governance into the design of the AI solution from day one. In non‑AI systems, design‑time governance is often skipped because of cost. With AI, I strongly advise making governance and compliance a design pillar, aligned to the standards and regulations that actually apply to your business and use case—not to everything under the sun.
Interviewer: How do you enforce policy‑as‑code so that governance runs through CI/CD and monitoring?
Bogdan: I challenge the popular view that you can effectively enforce policy‑as‑code where AI systems are involved. In deterministic systems, yes—policy‑as‑code through CI/CD pipelines is well established, subject to your regulatory environment and jurisdictions. But with non‑deterministic AI, you do not control outputs the way you control inputs. Enforcing policy on outputs would require the capability to change code or policies at any time, 24×7×365, with significant cost and complexity. There may be niche domains (e.g., certain defence contexts) where this is justified, but generally it’s not practical.
Instead, invest in excellent observability, robust fail‑safes and zero‑downtime mechanisms. A couple of concrete examples:
In voice channels, observe speech‑to‑text latency end‑to‑end. Users speak into a microphone; software converts speech to text. The technology is mature, but networks, noise and other factors outside your direct control affect latency. Once you hit a few seconds—around the three‑to‑five‑second range—customer experience degrades rapidly. Under three seconds is typically tolerable. Monitor, alert and tune for that. On the staff side, if the desktop or mobile app used by agents becomes unresponsive or sluggish, implement dynamic endpoint controls to restart the app automatically when benchmarked thresholds are exceeded. Don’t restart after a brief stall; use measured triggers. A clean restart often fixes the issue quickly without human intervention.
There are many more patterns, but the principle stands: prioritise observability and engineered fail‑safes over trying to encode policies against inherently variable outputs.
Interviewer: How should observability differ across channels such as chat, voice and video?
Bogdan: It is context dependent. Chat is lower touch than voice, so you have more leeway. Video and audio are the highest touch. Observability must account for the physical world, not just software. Low latency matters, but the drivers include environmental factors such as background noise and transient or persistent network conditions. You are monitoring a system influenced by physics.
Interviewer: Beyond what customers explicitly say, what other signals should you look for to understand and improve the experience?
Bogdan: Stay connected to the customer’s real world context. The signals you monitor vary by scenario. In some contexts, speech to text latency is less critical. In others, it is crucial, especially at the front door during authentication or in retail when a customer wants to amend an order or track a high value purchase. If speech to text becomes sluggish due to noise spikes, network variability or other environmental factors, you need benchmarks and rapid response. Use a fail safe: after a small number of retries, hand over to a human agent. The more important the customer need, the faster you should route to a person to remove friction and protect the experience.
Interviewer: How do you trigger and orchestrate fallback when confidence or safety thresholds are breached, and how do you quantify the customer impact?
Bogdan: Decouple immediately. Hand the customer from the automated flow to a manual flow because you no longer trust the system in that moment. You will investigate and fix in parallel, but the customer experience operates on seconds. Use a manual fail safe and send the interaction to an agent, even if that means a general queue staffed to respond quickly. That preserves trust if it remains the exception rather than the norm.
Interviewer: What key AI trends will shape the technology landscape, and how will they influence business adoption and cost?
Bogdan: The cost shock driven by generative AI is significant and spills into everything with electronics, with or without AI. Memory prices have risen sharply in a short period. CPU prices are also up. Demand for compute, especially GPUs and specific memory types, has outstripped available capacity, so manufacturers have shifted production. Hyperscalers have increased prices, which affects you even if you use little or no generative AI. For enterprises, that can mean extra spend ranging from millions to much more, without added value. The labour market also feels the impact as businesses adjust margins, hiring and overtime. In my view, there has been no clear return on investment at meaningful scale for generative AI to date, and even forecasting ROI with confidence has been difficult.
Interviewer: How should businesses use AI to boost ROI if generative AI does not provide it directly?
Bogdan: Do not default to generative AI in production. Start with the problems you need to solve and analyse the cost model carefully, especially if public cloud is involved. The cost model is complex, but it can make or break the case. Encourage safe experimentation for employees, but keep generative AI out of production until you have a solid use case with a foreseeable and real return, even if small. Governance and regulation add cost, yet they reduce risk. Generative AI expands the risk profile, which translates into cost. Do not gamble with customer data or reputation. Wait until the business case and controls are clear.
Interviewer: How has the ecosystem and community evolved from your perspective?
Bogdan: At The AI Summit there is a lot of diversity and some chaos, which is natural when many different people come together. It is an orderly kind of chaos. The opportunities are wide. You can connect before the event through the app and on LinkedIn, which raises the value of the two days. People are open to talk. You often discover something genuinely new and important to your work, which you can act on after the summit.
Interviewer: Why is it valuable for the community and industry to meet here?
Bogdan: People learn from each other and they also do business together. Relationships start here, and it is up to everyone to follow up. You can feel the pulse of the market if you do the legwork. You can go deep technically, or into marketing, security and other disciplines. You could search online, but in person is ten or a hundred times faster and better because you get direct context. It also gets you away from the desk and moving through the venue. It is not exercise, but it is a healthy break that delivers real return.
Interviewer: For someone who has never been and plans to implement AI in their business, what advice would you give about attending The AI Summit London?
Bogdan: Plan ahead. Do not decide a week before. The two days look similar but they are different, with many parallel sessions. Plan at least three or four weeks in advance, ideally a quarter ahead. Review your roadmap for this year and next, identify major objectives and the people you want to meet, and connect through the event app and LinkedIn. Be clear about what you want to get out of it, but stay flexible because you will discover new opportunities and your plan will improve. If timing clashes with something like a product launch, consider sending colleagues. The key is to think about it a few months in advance so you can extract maximum value.
Closing
Thank you to Bogdan Grigorescu for these pragmatic insights.
Key takeaways:
- Keep authentication deterministic and segregated from chat interfaces.
- Design a tested kill switch into critical AI systems; embed governance at design time aligned to DORA, the GDPR and your sector’s obligations
- Prioritise observability and fail‑safe operations over policy‑as‑code for non‑deterministic outputs. That’s how to build trust, control and reliability at scale.















