AI Cameras in Operating Rooms: Benefits and Risks
VitVio is bringing AI cameras to a Polish teaching hospital. See how operating room AI could improve workflow—and what hospitals must resolve first.
AI Cameras in Operating Rooms: Efficiency, Oversight and Trust
An operating room is high-stakes, but the day-to-day bottlenecks are often pretty ordinary: a room isn't ready, the right equipment isn't there, a case runs late, or the next team isn't sure when to get prepared. AI cameras that watch operating-room activity could make those problems easier to see. They also bring cameras into a space where staff and patients don't really have meaningful ways to opt out.
London-based VitVio is rolling out its Vetro camera and sensor platform in selected operating rooms at the University Clinical Centre in Gdańsk, Poland. The hospital is the first in Poland to adopt the system, according to The Next Web's report. Vetro is described as logging stages of surgery, flagging delays, and helping teams prepare between cases. In this deployment, it's not presented as a tool for diagnosing patients or guiding clinical decisions.
That distinction helps, but it doesn't end the conversation. Hospitals still need to understand what the system records, how its outputs are used, who can access the data, and what rules govern that access. This article looks at the operational case for AI cameras, the regulatory boundary around workplace monitoring, and the practical checks a hospital should run before expanding a pilot.
What VitVio is deploying in Gdańsk
Vetro combines multiple cameras with ambient sensors. VitVio says its platform turns continuous capture into a live geometric model of the room. Its software agents then recognise workflow stages and coordinate activity between cases. The initial deployment is in selected rooms at the University Clinical Centre, a teaching hospital affiliated with the Medical University of Gdańsk.
The stated use is operational: record stages, identify delays, and help teams prepare. Instrument tracking and operative notes are described as future capabilities, not things already in use in this hospital. Keeping that distinction clear matters. A system that observes room activity to improve scheduling is a different proposition from one that recommends treatment or interprets clinical findings. Still, even "operational" uses can have real consequences for the people in the room.
VitVio is a London company, not a Polish one. Its first pilot was at the Royal Orthopaedic Hospital NHS Foundation Trust in the UK, and its COO has pointed to the founding team's Polish roots when describing the connection to the Gdańsk project. The company raised €1.8 million in pre-seed funding in January 2025, then an $8 million seed round later, based on the reporting provided for this story. Medim, a Polish distributor, is coordinating installation.
The hospital's size adds context. It lists 1,241 beds and 4,834 employees. A large teaching hospital has complicated schedules, multiple specialist teams, and constant pressure to use operating capacity well. Even a modest reduction in avoidable room downtime could matter. But scale also makes governance trickier: a pilot can quickly affect a lot of people if it expands without a clear "stop and decide" point.
What the cameras do - and what is not yet public
The public description doesn't answer several practical questions about how the system works day to day. The hospital and company have not publicly detailed the data retention period, hosting location, access controls, or the role-based permissions available to staff. The source also doesn't say how the system handles edge cases - like unusual cases that don't fit the workflow model it's been built around.
VitVio says Vetro strips identifiable data in real time and does not create biometric templates. Those are relevant privacy claims, but they don't complete the picture. De-identification doesn't automatically mean that no one can be singled out - especially in a small team or with time-stamped records tied to a specific procedure. Hospitals need to understand the full data flow, not just trust a single label like "anonymous."
It's also worth not assuming features from one product automatically carry over to another. The source compares Vetro with Teton, a Danish system that turns video into 3D representations and reportedly deletes footage. Whatever Teton does there belongs to Teton, not necessarily VitVio. Similar technical architectures can still make different choices about what gets captured, stored, and made available.
The operational case for AI in operating rooms
Hospitals don't need AI for AI's sake. They need reliable ways to use scarce staff, rooms, and equipment. Operating rooms are expensive, and delays cascade: a late start affects the next case, shifts staff schedules, reduces recovery capacity, and sometimes changes patient access. If a system can provide timely information about how rooms are being used, it may help managers find friction that's actually fixable.
The most likely early benefit isn't autonomous decision-making. It's better measurement. A lot of organisations still lean on manual timestamps, retrospective reports, or local definitions that don't line up neatly - like when a case "begins" or "ends." Automated observation can give teams a more consistent view of things like turnover time or preparation time. That helps separate a genuine process problem from a story that sounds plausible but doesn't hold up under measurement.
A useful system should answer questions like:
- Where does avoidable waiting happen, and how often?
- Which delays are within a team's control, and which depend on upstream factors?
- Does better coordination reduce room downtime without increasing staff workload?
- Are the results consistent across procedure types, shifts, and teams?
- Can the information support changes staff believe are safe and workable?
These questions are more useful than asking whether the AI can "understand" an operating room. Recognition is a technical feature; value is an operational outcome. A system might detect stages accurately and still fail to help if the hospital can't act on the output - or if the categories it uses don't match how teams actually work.
Measure the system against a baseline
If you're serious about a pilot, you measure before the cameras arrive. Otherwise you're left guessing whether things improved because of the system or because people were already changing workflows. The baseline should use agreed definitions and account for differences in case complexity, staffing, equipment, and scheduling.
The evaluation should include both benefits and costs. That can include room turnaround time, delays between scheduled cases, cancellation rates, and staff time spent coordinating. It should also record errors, missing data, false alerts, workflow interruptions, and the time required for staff to review or correct outputs. A dashboard can look crisp while still being wrong in ways that matter.
There's also a broader workforce shortage behind the business case. The source cites an EU shortfall of around 1.2 million doctors, nurses, and midwives. In that context, reducing avoidable administrative work can be worthwhile. But "efficiency" shouldn't become shorthand for asking the same people to do more with less. If the system increases surveillance pressure or adds documentation work, the trade-off needs to be spelled out - not assumed.
A useful comparison is a reported deployment in Denmark. Teton's system has been used for more than a year, and the company claims a 25% reduction in night-shift workload. That's still a company claim, not proof that the same effect will show up in Gdańsk. The operating model, staff roles, and measurement methods may differ. It's a reason to ask for evaluation data, not something to apply as a prediction.
Why worker monitoring changes the risk profile
A camera in an operating room doesn't just observe a room. Depending on its purpose and configuration, it can generate information about how employees behave, how quickly they complete tasks, and whether they follow procedures. That can move a workflow tool closer to workplace monitoring - and change the risks around staff privacy, management decisions, and regulatory classification.
The EU AI Act includes high-risk rules for certain AI systems intended to monitor or evaluate workers' behaviour. The source reports that the relevant provisions (alongside several other categories) were delayed to December 2027 under an Omnibus process. That's a reported regulatory timeline. Hospitals and vendors should confirm the current legal position and implementation guidance before relying on it. A delay in application isn't the same thing as permission to ignore existing obligations.
Purpose matters, too. VitVio's earlier launch materials reportedly described tracking adherence to safety protocols, flagging deviations, and producing post-surgery debrief reports. The Gdańsk announcement focuses on logging stages, flagging delays, and helping teams prepare. Those descriptions aren't interchangeable. The more a system is used to assess individual conduct or performance, the more directly worker-monitoring rules may apply.
And "intended purpose" isn't set only by what's written in marketing. Configuration, user access, deployment practices, and what people actually do with the outputs all matter. A tool introduced to coordinate room use can become performance management if managers start using individual-level records to rank staff or discipline them. That's why the hospital needs a clear written boundary for permitted use - not just a vendor description.
GDPR and meaningful staff involvement
The source says VitVio's privacy policy identifies the hospital as the data controller and VitVio as the processor. That's a starting point, not a deployment-specific assessment. The hospital still needs to document what personal data is processed, why, which legal basis applies, how long it's kept, and who can access it. If the data could reveal health information or other sensitive details, the assessment needs to reflect the actual setting and the real risks.
Consent is especially tricky in employment. Workers may not feel they can refuse an employer's request, so consent often isn't a reliable basis for workplace processing. Staff involvement shouldn't be reduced to asking people to sign a notice after the decision is already made. Representatives and clinical teams need a genuine chance to question the purpose, test safeguards, and raise concerns before the deployment expands.
Hospitals should also separate "privacy controls" from "employment controls." Removing names or faces may reduce some privacy risks, but it doesn't stop managers from using patterns to evaluate teams. Likewise, banning individual performance scoring doesn't answer questions like how footage is secured or whether third parties can access it. Both layers require explicit control - not vibes.
What hospitals should verify before scaling
Treat a pilot as a bounded operational test, not as an automatic step toward rolling the system out across the hospital. Before adding rooms or new use cases, the hospital should require evidence that the system solves a defined problem without creating disproportionate risks. That means looking at the technology, the data arrangements, and how the organisation will use it.
A practical review can be organised around five areas:
- Purpose: Write down permitted use in plain language. Is it measuring room flow, coordinating turnover, or assessing adherence to protocols? Avoid vague claims like "improving efficiency."
- Data flow: Map what cameras and sensors capture, what gets processed locally or remotely, what's stored, when it's deleted, and who can access it. Confirm the answers contractually.
- Human impact: Identify who may be affected, how outputs could influence staffing or performance decisions, and how staff can challenge inaccurate records.
- System quality: Test accuracy across different procedures, room layouts, and shift conditions. Record failure cases and set a process for human review.
- Value: Compare outcomes against a baseline before deployment, including the costs of implementation, oversight, and staff time.
This review should involve clinicians, theatre managers, information security, data protection, procurement, and staff representatives. Each group sees different failure modes. Clinicians are closest to exceptions in care delivery. IT and security teams can assess architecture and access. Data protection specialists can examine processing and rights. Procurement can make sure obligations survive the pilot and any change in vendor ownership or service arrangements.
Put boundaries into the deployment, not only the policy
Policies are useful, but technical and operational controls are what make them enforceable. If individual performance scoring is out of scope, the product shouldn't expose individual rankings to managers. If raw footage isn't needed after processing, retention should be limited and verifiable. If the data is only for room-flow analysis, access and reporting should match that purpose.
Hospitals should ask vendors for concrete answers to questions like:
- Is raw video kept, and if so, for how long and where?
- Can hospital staff, the vendor, or subcontractors view footage or derived data?
- What's the process for correcting an incorrectly recognised event?
- How does the system behave when it can't classify an activity with confidence?
- Are outputs linked to identifiable staff, patients, or specific procedures?
- Can data be reused to train models, and can the hospital refuse that use?
- What happens to data when the contract ends?
The answers should show up in technical configuration, contractual terms, and staff-facing explanations. If the product changes - for example, by adding instrument tracking or generating operative notes - the hospital should reassess purpose and risk. Treat it as more than a routine software update.
There's a real trade-off here. More detailed data can make workflow analysis better, but it can also make people and cases easier to identify. More aggressive deletion can reduce exposure, but it can also limit the ability to investigate a wrong or misleading output. The right balance depends on the use case. The point is to make that balance explicit and documented, instead of leaving it to default product settings.
Conclusion: measure the workflow, not just the technology
AI cameras could help hospitals spot where operating-room time is going and coordinate teams more effectively. VitVio's Gdańsk deployment is a concrete test of that idea in a large teaching hospital facing the same capacity pressures seen across Europe. But whether it's useful will depend less on the cameras themselves and more on whether the system produces reliable, actionable information within clear limits.
The practical approach is straightforward: define the use, set a baseline, document the data flow, involve staff, and measure both benefits and side effects. Keep workflow improvement separate from individual performance evaluation unless there's a clear, lawful, and openly governed reason to combine them. Reassess if the product or the purpose changes.
If your organisation is considering AI monitoring in a clinical workplace, start with a specific operational problem and a bounded pilot. Ask for the evidence and data terms before expanding. A system that runs safely and answers a real question is more valuable than a technically impressive deployment that nobody trusts.