Frequently Asked Questions

Glotech is an AI infrastructure and MLOps consultancy focused on taking AI systems from development into reliable production. We work across AI architecture, MLOps, cloud infrastructure, DevOps, observability, computer vision, and AI system integration.

We build the infrastructure and engineering systems that allow AI applications to run reliably in production. This includes model training and serving pipelines, cloud-native architectures, Kubernetes platforms, CI/CD, observability, computer vision systems, data pipelines, and AI integrations.

No. AWS is a major part of our work, but Glotech also works with Google Cloud and cloud-agnostic technologies such as Kubernetes, Terraform, Docker, Prometheus, Grafana, and MLflow.

Both. Depending on the project, we can work across the full path from data and model development to deployment and production operations.

MLOps is the engineering discipline of making machine-learning systems reproducible, deployable, observable, and maintainable in production. It brings software-engineering and infrastructure practices such as versioning, CI/CD, monitoring, experiment tracking, and automated deployment into the ML lifecycle.

Yes. We can work with an existing system rather than requiring a project to start from scratch. Depending on the situation, that can mean improving deployment, infrastructure, observability, scalability, model-serving architecture, or the ML lifecycle.

Yes. Glotech builds production computer-vision systems, including inference pipelines, data-centric training workflows, edge and cloud deployment, model monitoring, and human-in-the-loop review.

Yes. Glotech can design deployments around a customer's existing network, cameras, ERP systems, and security requirements. Where systems cannot or should not be exposed to the public internet, edge infrastructure can be deployed inside the customer's environment and used to securely exchange only the data required by the application.

Glotech IT Solutions OÜ is based in Tallinn, Estonia. The company's public website lists Sepapaja tn 6, 11415 Tallinn, Estonia.

For general enquiries, contact [email protected].

Kaya is Glotech's industrial AI product. It measures equipment runtime by reading the equipment's existing tower light through camera footage and turns that signal into machine-level runtime and reporting data for invoicing, quoting, capacity planning, and operational analysis.

No. Kaya is a product developed by Glotech for equipment-runtime measurement. Glotech's consultancy work and Kaya are separate offerings.

Kaya is not limited to a particular machine manufacturer or industry. The key requirement is that the equipment has a visible tower light or signal lamp and that a camera can see it. This can include CNC machines, presses, moulding equipment, packaging lines, assembly cells, robotic cells, test equipment, and other industrial machinery.

Kaya is particularly relevant to businesses that need defensible equipment-hour measurements, for example contract manufacturers, businesses that invoice by the hour, and operations that need comparable runtime data across mixed equipment or multiple sites.

Kaya is not suitable for equipment without a visible signal lamp. It is also not the right tool if you need internal controller data, direct machine control, safety functions, or a complete OEE calculation from Kaya alone.

No. Kaya measures Availability, but it does not produce the Performance and Quality components when the required data is unavailable. Performance requires part counts and an ideal cycle time; Quality requires good-versus-scrap counts.

No. Kaya does not attach sensors, switches, current clamps, or other hardware to the equipment. It reads the tower light using cameras.

No. Kaya does not need access to the machine controller, PLC, G-code, or machine protocol. Runtime is determined from the equipment's external tower-light signal.

No. Nothing is installed on or inside the equipment, and the machines do not need to be opened, rewired, reconfigured, or taken out of production. Operators do not need to change their normal workflow.

Not necessarily. Kaya is designed to use existing factory CCTV when the cameras can clearly see the equipment's tower lights. If coverage is insufficient, additional cameras may be needed.

It depends on the factory's network and security requirements. If the camera recorder can be securely accessed from the Kaya service, Kaya can use the existing camera infrastructure without installing equipment on the production floor. If the factory does not permit external access to its cameras or internal systems, Kaya can deploy an AWS IoT Greengrass edge device inside the factory network. The device communicates securely with Kaya's AWS infrastructure and transfers the data required for processing. The edge device sits on the factory network; it is not installed on, connected to, or dependent on any production machine.

No. A factory can keep its cameras and NVR/DVR completely private. Where external access is not permitted, Kaya can use an AWS Greengrass deployment inside the factory network. The edge deployment handles the required communication with Kaya's cloud services without requiring the factory to expose its camera infrastructure publicly.

Setup includes the company and site, camera configuration, machine list, camera-to-machine mapping, and relevant operator information. The camera view is used to define zones around each machine's tower light and, where needed, the operator area or motion area.

The camera-to-machine mapping can be updated through the zone editor. Mappings are versioned with revision numbers and timestamps, so changes do not silently overwrite historical configuration.

Yes. Kaya uses AWS IoT Greengrass for edge deployments where processing or data access needs to happen inside the factory network, while maintaining secure communication with Kaya's AWS infrastructure.

Yes. Kaya does not require the ERP to be hosted by Glotech. If the customer's ERP is hosted in its own environment, Kaya can integrate with it according to the customer's network and security requirements. Where direct external access is not permitted, an edge deployment can securely retrieve and transfer the relevant ERP data needed by Kaya. ERP data provides context such as work orders, machine assignments, operators, parts, and customers; it does not determine whether the machine was actually running.

No. Kaya only needs the ERP information required for the configured integration and reporting use cases. The runtime measurement itself comes from the tower light.

No. ERP integration is optional. Kaya can measure runtime without an ERP. An ERP connection adds context such as work orders, machines, operators, parts, and customers, allowing runtime to be attributed to jobs and customers.

No. The tower light is the authoritative runtime signal. ERP data provides context around the measured hours but cannot create, remove, or redefine runtime.

The exact architecture depends on the customer's requirements. For factories that prohibit inbound access to cameras or internal systems, the edge deployment keeps those systems private while securely exchanging the data Kaya requires.

No. For customers that do not permit inbound access to factory systems, Kaya can use an edge deployment inside the customer's network.

Kaya measures equipment states based on the tower light and whether the machine is attended. It can report producing, stopped, alarm, unattended, and no-evidence periods.

No. If a machine is lit but nobody is present, Kaya reports that time separately as unattended and excludes it from billable runtime.

It does not guess. If a camera is unavailable, the lamp is blocked, or the image is not good enough, Kaya records the period as no evidence rather than inventing a machine state.

Kaya does not silently assume that the machine continued running. Periods without sufficient evidence are reported as such, so zero runtime is never confused with unmeasured time.

Yes. Kaya links reported runtime back to the camera imagery used to make the measurement, including the tower-light state, detected people, neighbouring frames, and the state progression.

Potentially, yes. If the site's camera recorder still retains the relevant footage, Kaya can analyse historical recordings, limited by the recorder's retention period.

Yes. Part and cycle counting is an optional capability using movement within a defined camera zone, independent of the runtime measurement.

No. Kaya only determines whether a defined machine area is occupied. It does not identify individuals, track people between machines, or provide named-person performance metrics.

No. Kaya measures and reports external machine activity and is intended to complement systems such as PLCs, MES, SCADA, or machine controllers rather than replace them.

Public product information does not publish a single accuracy percentage. Performance depends on the equipment, tower lights, camera coverage, image quality, and operating environment.

Kaya provides floor, day, machine, and customer-facing views, including producing hours, stopped and unattended time, machine sessions, work-order coverage, customer attribution, and optional part and cycle counts. Reports can be exported to print, PDF, and CSV.

Yes. Kaya can connect to the customer's own AI assistant to help with onboarding, retrieve machine and site information, answer questions about runtime, and retrieve the evidence behind reported figures.

Questions such as: how many hours did this machine run last month; which machines had the most unattended time; what happened yesterday; why is this machine's runtime lower; how much did this customer use our machines; show me the evidence behind these hours.

Kaya's AWS deployment uses encryption in transit and at rest, role-based access controls, tenant isolation, audit logging, and authenticated Greengrass edge devices using unique X.509 identities and mutual TLS.

Pricing is not published in the public product information. Contact Glotech to discuss the appropriate deployment and commercial model.

Pilot availability and requirements depend on the site and deployment. Glotech can evaluate camera coverage, equipment, network architecture, ERP requirements, and security constraints.

The first question is whether your machines have tower lights that your cameras can see. After that, the important questions are camera coverage, recorder retention, network accessibility, and whether ERP attribution is required.

Visit glotech.io/kaya or contact [email protected].