Discussion Board 4.5: Think & Share 💡The Deployment Decision

While cybersecurity and data privacy are obvious concerns, I believe the biggest long-term risk is actually moving too slowly. In highly regulated industries like banking, excessive caution can cause organizations to miss opportunities while competitors become more efficient and innovative. This is more of my gut feeling than something I have personally experienced.

I do not think testing should be based on a fixed number of tests. Instead, each feature should be validated individually, followed by end-to-end workflow testing and a gradual rollout to a small group of users before full deployment.

Accountability should be shared. The business owner is responsible for defining the requirements and validating the outputs, while IT is responsible for the technical implementation, security and reliability. The manager approving the deployment should also be accountable for ensuring adequate governance and testing.

I believe the real challenge is not whether to adopt AI, but how to adopt it responsibly without falling behind competitors.

Recently, I saw a demo of an AI mobile app that records conversations between sales reps and doctors. It can summarize the discussion, capture follow-up actions, and even suggest an agenda for the next visit. I think it’s a great way to reduce administrative work.

My biggest concern would be privacy, compliance, and whether the AI captures the conversation accurately. These discussions could contain patient or commercially sensitive information, so consent and proper governance are important. If the AI gets it wrong, it could affect follow-up actions and even the relationship with the customer.

I also think accountability shouldn’t sit with just one team. The business owner, AI team, IT, data governance, compliance, and end users all have a role to play in making sure the solution is properly tested, monitored, and used responsibly.

AI adoption is no longer the question—the real challenge is whether our engineering and governance practices are evolving at the same pace as AI. AI has undoubtedly accelerated software development, but writing code is only one part of building reliable software. What I often see missing is the corresponding evolution of software delivery processes. As AI increases development velocity, organisations must strengthen governance, risk assessment, testing strategies, human-in-the-loop decision points, traceability and deployment controls to match that acceleration. Without these, we simply create defects faster and at greater scale.

For that reason, the risk that concerns me most is deploying AI-assisted applications without adequate governance and quality controls. Accountability cannot rest solely with the developer or the AI tool—it must be shared across leadership, product owners, engineering, quality engineering and risk functions that collectively decide the application's readiness for production. There is also no universal definition of "enough testing." The level of assurance should be driven by risk: applications handling sensitive data, influencing business decisions or supporting critical operations require significantly more rigorous validation, including functional, security, performance and AI-specific testing, together with continuous production monitoring.

In my experience leading quality engineering for enterprise risk platforms, the greatest risk is not adopting AI too quickly or too slowly—it is accelerating development without equally maturing the governance, testing and decision-making processes needed to deploy AI responsibly.

Vibe coding allows users to describe an application in natural language while AI generates the code. Unlike traditional software development, which relies on specialist teams, formal requirements, architecture, coding and structured testing, vibe coding follows a rapid cycle of prompt, preview, test and refine. This lowers the barrier to creating software, but it also creates a danger: a polished prototype may appear reliable even when its logic, security or architecture is weak. The lecture therefore stresses that one successful demo proves only that one path worked once, not that the system is production-ready.

The risk that concerns me most is silent inaccuracy. A system failure is usually visible, but an application that continues operating while producing subtly wrong outputs may mislead users for weeks. In healthcare, this could involve incorrect clinical criteria, drug information, calculations or research interpretations. Because these errors can look credible, they may be trusted before being detected.

Accountability must remain human. The person or organisation that approves and deploys the application should be responsible for the outcome. Technical teams, domain experts, security staff and management may share responsibilities, but there should be one clearly named owner. “The AI generated it” is not an acceptable defence.

There is no fixed amount of testing that is always enough. Testing should be proportionate to the consequences of failure. High-risk applications require domain validation, edge-case testing, privacy and security review, integration testing, audit trails, monitoring, rollback procedures and staged deployment.

In my experience, adopting AI too quickly is the greater immediate risk, especially in healthcare. However, moving too slowly creates a longer-term strategic risk. The best approach is to experiment rapidly in controlled, low-risk environments while transferring authority cautiously. My guiding principle is: Move fast in learning, but slowly in transferring decision-making power.

From my experience as an e-commerce director in Greece for almost 15 years, deploying and updating websites with ERP and CRM integrations, this is where I stand on this topic.

Which risk would concern you most?
For me it is architecture and integration failure. A demo can work perfectly one time, but this does not mean the system will hold when it has to serve more clients, more systems, more real use cases at the same time. I have seen this many times in practice. The problem is never the first successful test, the problem is everything you did not test yet.

Who should be accountable?
The one who approved the deployment, not the one who built it. The prototype did what it was supposed to do, it proved an idea can work. But the decision to actually put it live, with real users and real consequences, this is a human decision. So the accountability stays with the human who made that call, not with the tool.

How much testing is enough?
Enough to try and break it, not only to use it the way you expect people to use it. In my career I have postponed website launches more than once, not because something failed in the demo, but because I could not yet answer what happens when someone uses it wrong, or when an ERP or CRM integration sends something we did not plan for. One good test only proves one path works, one time.

Is the greater risk moving too fast or too slow?
Honestly, I prefer to lose some time than to lose trust. If you launch too fast and it breaks in front of a client, you do not only lose that project, you lose the relationship and probably future referrals too. But I also do not believe in waiting forever, this is a risk on its own. The real goal is not to avoid risk completely, it is to know exactly which risk you are taking before you take it.

Imagine an AI-generated application is deployed after a successful demonstration. Several weeks later, unexpected issues emerge, resulting in inaccurate outputs and operational disruption. Which risk would concern you most in this situation and why?

Innovation cannot be controlled. However, when developing R&D solutions as part of a strategic solution, there should be proper controls, governance, and continuous monitoring. There are tools that can be used to trace the results and capture how the AI agent arrived at its reasoning. This helps identify issues early and reduces the impact of inaccurate outputs.

Who should be accountable when an AI-assisted application causes harm or business disruption?

There are ways to identify how the solution arrived at its decision. Based on that, we can determine who should be held accountable. Accountability should be established by tracing the reasoning, implementation, and oversight behind the solution.

How much testing is enough before deployment?

Testing is never enough. However, there should be identification of existing use cases, and any alien or edge cases should be guarded against by ensuring the model does not respond to scenarios it was not designed to handle, such as prompt injection attacks. The model's memory should also be controlled, including what information can be stored and for how long, so that it does not retain incorrect or outdated information that could bias future outputs.

In your experience, is the greater risk adopting AI too quickly or moving too slowly?

The greater risk is always moving too slowly. Moving quickly or slowly does not make you risk-free. What matters is how much governance is in place to identify, manage, and mitigate risks if they occur.

1. Which risk would concern you most in this situation and why?

The risk that would concern me most is reputational risk, particularly in the financial services industry where I have worked. Once an organisation deploys an AI-assisted application, customers and stakeholders expect the outputs to be accurate, reliable, and trustworthy. If the AI generates incorrect information or makes poor decisions, it can quickly damage the organisation's credibility and erode customer trust.

For example, if an AI application generated incorrect market commentary for client reports, it could misinform investment decisions, expose the organisation to financial and regulatory risks, and significantly damage its reputation. Rebuilding trust after such an incident is often far more difficult than fixing the technical problem itself.

2. Who should be accountable when an AI-assisted application causes harm or business disruption?

Accountability should be shared across everyone involved in designing, developing, testing, and deploying the solution, as each team has responsibility for its part of the process.

However, the final accountability should rest with the business owner or senior leader who approves the application for production. That individual is responsible for ensuring that appropriate governance, testing, security reviews, risk assessments, and business sign-offs have been completed before deployment.

AI should support decision-making, but the responsibility for approving business-critical systems should always remain with humans.

3. How much testing is enough before deployment?

For business-critical AI applications, there is no such thing as "too much testing." Before deployment, I would expect:

Comprehensive functional testing covering every feature and workflow.
Validation of AI-generated outputs against trusted data sources.
Testing of all user journeys, buttons, forms, APIs, and integrations.
Security, performance, and scalability testing.
Negative testing using unusual or incomplete inputs.
User Acceptance Testing (UAT) with business stakeholders.
A deployment readiness checklist confirming that all quality gates have been completed.

Even after deployment, AI applications should continue to be monitored because models and data can change over time. Human oversight and ongoing validation remain essential.

4. In your experience, is the greater risk adopting AI too quickly or moving too slowly?

Based on my experience, adopting AI too quickly without appropriate governance presents the greater risk.

While organisations that move slowly may lose competitive advantage, rushing AI into production without sufficient validation can result in inaccurate outputs, operational disruption, financial loss, regulatory issues, and long-term reputational damage.

For example, in financial services, I worked on client reporting processes where market commentary is included in reports sent to clients. If an AI solution generated inaccurate or misleading commentary, it could expose the organisation to financial, compliance, and reputational risks. This demonstrates why AI-generated content should always include human review before publication.

That said, organisations should also avoid moving too slowly. A balanced approach-starting with controlled pilots, implementing governance and guardrails, learning from early deployments, and then scaling gradually-helps organisations realise AI's benefits while managing risk effectively.

The risk that worries me most is false confidence from a successful demonstration. A demo only proves the happy path works once, it doesn't prove the system holds up under real data, edge cases, or repeated use over time. That's why a one-off demo isn't enough, you need iterative testing that keeps probing the app as conditions change, not a single pass or fail moment before go-live.

On accountability, I don't think "AI built it" changes who's responsible. It should still sit with whoever approved the deployment and signed off that testing was sufficient. If there wasn't a real sign-off step because the build felt quick and low-risk, that's the actual gap not the AI itself.

As for testing, I'd scale it to impact, not to how fast the thing was built or how good the demo looked. If it touches sensitive data or influences a decision, it needs ongoing, iterative validation, not a single demonstration treated as proof it's production ready.

In my experience the bigger risk isn't adopting AI too fast, it's not updating our governance to keep up with how fast we can now build. That's usually where things slip through.