AI in sports: where data exists but decisions don't work
Wearable sensors and arena cameras already provide raw material: heart rate telemetry, acceleration and movement data across the court, video from multiple angles, match protocol.
Athlete data accumulates season after season, but the coaching staff still makes lineup and workload decisions by eye — there is no layer between the recordings and the decision that turns them into insight.
Match analysis rests on a single analyst: they manually cut episodes, tag duels and turnovers, and compile the numbers into a table. Such analysis is not always ready by morning training, and by the next match it loses half its value.
AI adoption in sports is held back not by model quality, but by this gap between recording and decision.
The situation is worse with dynamics. Sensor exports, medical records, and workload diaries sit in different systems, and there is no single key per player.
Because of this, overloads and injuries are visible only in hindsight: first the player drops out of the lineup, then an explanation is found in the data — too much volume last week, insufficient recovery, a series of micro-injuries.
The window in which overload can still be relieved by adjusting the plan is just a few days. When the signal comes after the fact, only treatment and lineup restructuring remain, not prevention.
At the same time, the coach spends time compiling reporting: player summaries, minutes, zones, workloads — everything is compiled manually from the same exports.
Coach reporting stops being a daily routine only when data is collected automatically and the output includes ready-made analysis and risk flags. Let's break down how this is addressed.
What adoption changes: effects that are measured
The effects start with data that was previously lost. Streams from sensors and trackers — in sports, most often Catapult and similar positioning systems — are consolidated into a single workload profile per player: volume, intensity, accelerations, decelerations.
Then comes what a coach's log cannot provide: a comparable season-long history and comparison against a personal baseline.
Injury forecasting works not as prediction but as early warning. The model calculates the current week's deviation from the athlete's baseline and highlights accumulating overload several days before they feel the problem themselves.
A whole class of errors disappears — "noticed after the fact, when the player was already out": the staff receives a signal while the workload can still be adjusted.
Video analysis stops being an evening routine. The system tags episodes by match events and assembles clips by player or situation type, so the coach sits down not to edit but to analyze.
Report preparation is reduced severalfold: a draft with counters, diagrams, and clips is assembled automatically, and the person only adds conclusions.
Recovery monitoring closes the loop. Sleep, resting heart rate, and subjective assessments are consolidated into a single readiness scale, and the training plan is adjusted based on it, not on feel.
In total, the club measures three values: the share of overloads noticed in advance, time spent preparing analysis, and the number of missed matches.
Deployment formats: cloud, club perimeter, or hybrid
The processing deployment format determines three things: the delay between an event and analysis, the load on the club's channel, and requirements for protecting athletes' personal data.
There is no universal option — the choice is dictated by the size of the video archive, the number of cameras, and data sensitivity.
Cloud processing provides a fast start: you don't need to keep the capacity for video analysis in-house. The price is that the source stream from multiple cameras runs into the venue's channel, and training footage and metrics leave the club.
A local perimeter resolves the transmission issue but requires its own resources and a model update procedure. A hybrid scheme divides the perimeter by data type: sensitive data stays inside, while heavy video analysis goes outside.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud processing | One-off projects and clubs without their own capacity that need a fast launch | Dependence on the channel, delay in stream analysis, need for encryption and a personal data processing agreement |
| Local perimeter | Medical and biometric data, requirement to store them on club premises | Long launch, manual model updates, own reserves for the video archive |
| Hybrid scheme | Ongoing work with multi-camera video and sensitive metrics | More complex operations: a routing layer and a registry of which data goes where are needed |
In practice, the scheme is chosen based on three inputs: how many cameras record simultaneously, how long the video archive must be stored, and whether there is a requirement to keep athletes' personal data inside the club. We assemble the configuration around these parameters.
Engineering stages: from data audit to handover
We start not with the model but with data inventory: without understanding what is actually recorded and how regularly, any processing produces beautiful but incorrect numbers. The data audit comes first, and it is most often what changes the work plan.
- Data audit. We look at what exists: tracking systems, video, manual protocols, sensor recordings. For each source — history depth, gaps, format changes between seasons. The output is a list of what can be relied on and what will have to be restored.
- Data schema. We bring different seasons into a single model: match, player, time segment, event. Without this, comparison of periods and players does not add up — the features simply do not match in meaning.
- Event labeling. We fix the list of event classes and rules for identifying them, write instructions for labelers, and launch cross-checks: a disputed segment is reviewed by a second person. The share of discrepancies shows whether the schema is unambiguous.
- Quality check. Control is performed for each event class separately, not by average accuracy: a rare event that is important to the coach should not dissolve in the overall figure.
- Processing setup. We make recalculation reproducible — the entire pipeline can be brought up from scratch on any dataset, and the result is saved with a version. This way two versions can be fairly compared on the same data.
- Validation on historical matches. We run the solution on past seasons and compare it with manual labeling. We keep the test set separate and do not use it during tuning — otherwise the evaluation is flattering.
- Staff training and solution handover. We show coaches and analysts where each number comes from and how to challenge it. We hand over access, the update procedure, and documentation — the solution continues to work without us.
What remains with you: solution package, schemas, and procedures
We hand over the package not as a "server that works at our place" but as a set of artifacts your team can use to deploy the processing perimeter, test it on your data, and develop it further without us. Below is what is physically included in the handover and why each document is needed.
- Configured processing perimeter — services for receiving and processing training and match data, all configuration in the repository, reproducible deployment in your environment: it can be redeployed with one command, not from memory.
- Data schema — which entities exist (athlete, session, metric, event), how they are related, where they are stored, what their lifecycle is, and what is cleaned up on a schedule.
- Data flow diagrams — the path from sensors, video, and manual input to marts and coach reports, with marked failure points and rules for reprocessing on failure.
- Model description — which features are input, what exactly is predicted, what data the model was trained on, how to read its confidence, and where the boundaries of applicability are: where a conclusion can be taken into a decision and where specialist review is needed.
- Access policies — roles (coach, analyst, doctor, administrator), what each sees and changes, action logging, and handling of medical data on the principle of minimum necessary access.
- Staff instructions — short guides: how to enter a training session, how to read a report, and what to do if session data did not load. Designed for a coach, not a programmer.
- Operations procedure — retraining frequency, output quality control, thresholds at which the model is considered degraded, rollback procedure to the previous version, and escalation procedure.
Together, this closes the main adoption risk: the solution works only while the contractor is nearby. With the documentation package and access rights, your team runs the system itself, and we get involved on a targeted basis — for retraining or expanding the dataset.
Case study: team workload analysis before and after adoption
It is telling that the problem was not a lack of data. Trackers on players and heart rate monitors recorded everything: distance, accelerations, heart rate zones.
The bottleneck was analysis — manually consolidating exports for each metric, so a report for a 25-person team was prepared by the end of the week, when it was already too late to adjust the plan.
How it was before adoption
The analyst consolidated data from Catapult with medical staff records into a separate table.
The team took about 20 hours of manual work per week, overload episodes were often found after training, and the decision to change the plan was made based on the coach's intuition rather than metric trends.
What changed after
We assembled a single perimeter: tracker and medical record data flow into one repository, the model calculates individual thresholds for each player and flags deviations.
The lineup report is generated automatically by the next morning — the cycle shrank from several days to hours. The share of overloads identified in advance (one to two training sessions before a breakdown) increased from about a quarter to two thirds.
In terms of before-and-after metrics: missed training sessions per season almost halved, and risk forecast accuracy on a two-week horizon reached a level at which the coach trusts the prompt without additional verification.
The model does not replace the staff: it highlights, the decision remains with the coach, and it is always visible which metrics the conclusion is based on.
How does video analytics differ from sensor telemetry?
Direct answer: they are two independent sources that answer different questions, and one does not replace the other. Video analytics describes what happens on the court, telemetry describes what happens with the athlete's body. The full picture emerges when the streams are synchronized to a single time.
Video analytics provides tracking of players and the ball, event labeling, and a model of team positioning.
It sees all participants at once, but data accuracy drops where lighting changes, players occlude each other, or the camera loses tracking — over a long segment, identity error accumulates.
Telemetry is responsible for physical output: accelerations, decelerations, distance, sprints, workload.
The sensor does not err in movement but does not know context — it does not distinguish a sprint in open space from a sprint under pressure, and when the signal drops, the segment is restored by an approximate model.
| Source | What it sees | Where it errs | In combination |
|---|---|---|---|
| Video analytics | tracking of players and the ball, event labeling, phases of play | occlusions, lighting, identity loss | events gain spatial context |
| Telemetry | accelerations, workload, distance, heart rate zones | no link to episode and opponent, signal gaps | explains the cost of each episode |
| Combination | episode and physiology together | requires precise clock synchronization | answers questions unavailable from a single stream |
The connection order is in two stages. First video analytics and event labeling: without understanding episodes, there is nothing to attach telemetry to.
Then sensors — synchronization to a single time brings both streams into one, and the question "how does a player sustain workload at the end" becomes computable rather than expert.
AI in sports: technical doubts and limitations
Objections to AI in sports are usually engineering-related, not conceptual: is there enough data volume, who will do the labeling, how to be accountable for quality, and is it realistic to scale the solution from one team to the whole club. We address each.
Not enough data — nothing to train on?
Volume comes not only from matches: training sessions, wearables, and injury and recovery logs provide a dense stream. If history is insufficient, we start with rules and statistics and bring in the model when the accumulated volume is sufficient for honest validation.
Will labeling have to be done manually?
We manually label only what affects the decision: key episodes, player states, outcomes. The rest is covered by domain rules and automated consistency checks — manual work remains for disputed cases.
Who is responsible for data quality?
At the input, there are checks for gaps, sensor outliers, and discrepancies between sources. Each dataset is recorded: it is visible what the training was based on and why the system produced a given recommendation.
How to scale from one team to the club?
The data schema and features are described once at the club level, and a team is connected as a separate slice. Adding a new team does not require rewriting the model, and comparison between teams remains correct.
Who controls recommendations?
The coaching staff makes the decision: the system proposes an option with justification and a confidence level. Discrepancies with actual results are returned to training — the logic becomes more accurate on real data.
Where we start: task discussion and work plan
In the first meeting, data and processes matter more to us than presentations: what is already being collected, in what form it is stored, and where the system should fit — into the work of the coach, analyst, or officiating crew.
In one conversation, we understand which inputs are missing for an honest scope estimate, rather than a "rough guess."
- history volume: how many matches, training sessions, or athletes are covered by recordings and device metrics;
- labeling: whether there are marked events and who on the client side can confirm their correctness;
- deployment perimeter: cloud, local server, or on-site equipment, requirements for personal data;
- integration points: where the result goes — to an application, report, coaching panel, or scoreboard;
- acceptance metric: what error rate on data not used in training we consider workable.
Next comes a short first stage. It is needed to check feasibility on your data and get a scope estimate based on facts, not assumptions.
- We examine the sample: find gaps, duplicates, and class imbalance.
- We build a baseline model and measure accuracy on a held-out portion of the data.
- We run it on a real scenario — with the same shooting and lighting conditions.
- We agree on the acceptance metric and timelines for full deployment.
- We deliver a report: what was confirmed, where the risks are, how much data needs to be added.
The first stage takes several weeks — after it, you have a working prototype and a work plan with clear timelines for each block. Describe the task: we will come back with an estimate and stages.
