CAN’s AI Workhorse Puts Secure Local AI Infrastructure to the Test

Contemporary Analysis has launched AI Workhorse despite a basic conflict in enterprise AI: adoption is rising, but costs and security concerns remain difficult to contain.

The Omaha data science consultancy, commonly called CAN, created Workhorse as a separate startup under its umbrella. Workhorse assembles dedicated servers, then places them at Scott Data Center for use by Nebraska organizations.

The pitch is not simply that local hardware can run an AI model. Companies already have several ways to rent cloud computing or buy servers. Workhorse instead argues that a dedicated node can offer predictable capacity, visible data location, and hands-on technical support.

That puts Workhorse against the dominant cloud-first route to enterprise AI. Cloud services provide fast access to advanced models without requiring customers to own infrastructure. However, usage charges, governance requirements, and sensitive data can complicate that convenience.

Workhorse enters this debate with only a handful of undisclosed clients. Its central claims have not yet received independent performance or security validation. The launch still deserves attention because it turns an abstract argument about private AI into a regional infrastructure test.

AI Workhorse Turns a Consulting Problem Into Hardware

Workhorse exists because CAN says its clients moved from AI experimentation toward questions about cost, control, and production deployment.

CAN Chief Strategy Officer Preston Badeer launched the startup several months before its public profile emerged in late July. According to the original AI Workhorse launch, the company builds servers that can run customized AI models.

Those servers are often called nodes. A node is an individual computing system that supplies processing, memory, storage, and network capacity to a larger workload.

Workhorse places its nodes at Scott Data Center, an Omaha facility that provides colocation and managed infrastructure. Customers can work through CAN or engage Workhorse directly.

The arrangement separates several jobs that cloud AI providers usually bundle together. Workhorse supplies the hardware. Scott Data hosts the equipment. CAN’s data scientists and engineers can help configure models and move applications into production.

That service layer matters because owning a server does not automatically create a useful AI system. A company must select a model, connect its data, control user access, evaluate outputs, and monitor performance.

The team says it can tune models for each node and support models developed internally by a customer. It also presents the system as an option for security professionals who cannot place certain workloads on shared cloud infrastructure.

CAN CEO Nate Watson described the physical control in unusually concrete terms. He said a customer could enter Scott Data and identify the exact hardware holding its model.

That visibility is central to the sales argument. A cloud customer usually controls accounts, permissions, and configuration. It rarely sees the physical machine processing each request.

Workhorse is also targeting repeat workloads rather than occasional chatbot use. A dedicated node becomes more relevant when an application runs continuously, handles sensitive records, or performs a stable set of tasks.

Potential examples include searching internal technical documents, reviewing contracts, classifying service requests, or assisting analysts with proprietary datasets. These are plausible applications, not disclosed Workhorse customer deployments.

Badeer declined to identify customers, citing security. He told Silicon Prairie News that Workhorse had a handful of clients and was courting enterprise organizations.

The company also said demand had absorbed its available inventory, with additional custom-built nodes planned. It has not published an order count, delivery schedule, hardware configuration, or independently audited utilization data.

Those omissions do not invalidate the concept. They establish the boundary between a launch narrative and a proven infrastructure business.

Why Secure AI Nodes Are Finding an Audience

The demand for private AI is not based on a single fear that a model vendor will take company data. It reflects several overlapping control problems.

Employees can expose confidential information by pasting it into unapproved tools. An approved application can retain more data than expected. An AI agent can also retrieve authorized information and combine it into a sensitive new output.

These risks exist even when the underlying model provider follows its contract. Data security depends on identity controls, retrieval permissions, logging, retention, model behavior, and employee practices.

The National Institute of Standards and Technology identifies privacy, information security, and value-chain integration among the risks requiring attention in its generative AI profile. NIST recommends managing AI risk across the system’s full lifecycle.

This broader view helps explain why local hardware attracts interest. A private node can reduce the number of outside systems touching data. It can also give an organization direct control over model files, logs, storage, and network connections.

However, physical locality is only one control. A poorly configured private server can remain vulnerable to stolen credentials, excessive permissions, malicious prompts, unpatched software, or insider misuse.

Local infrastructure therefore changes the security problem rather than eliminating it. The organization accepts more responsibility for configuration, updates, access control, monitoring, and incident response.

Trade secret concerns raise the stakes. Attorneys at Ropes & Gray recently advised companies to favor controlled environments where retention, access, training, and confidentiality terms can be governed. Their trade secret guidance also stresses policies, employee training, and periodic audits.

That guidance supports the direction behind Workhorse, but not every part of its pitch. Keeping a model on a known machine does not prevent an authorized employee from extracting sensitive output.

Agentic systems create another challenge. An AI agent is software that can plan and execute multiple actions, often by calling company tools or searching connected data.

An agent might read documents, query customer records, and draft a competitive analysis without copying any single file. Traditional monitoring may not treat that synthesis as a suspicious transfer.

A company running agents on private hardware still needs detailed logs and data-level permissions. It must know which repositories an agent accessed, which tools it called, and what it returned.

Workhorse can provide a controlled foundation for those measures. The customer must still implement them through software, policy, and continuous review.

For Nebraska companies, proximity creates another appeal. Teams can reach local operators, visit the facility, and work with consultants who understand the application.

That relationship can matter for midsize organizations without dedicated machine learning infrastructure teams. Their choice is rarely between an ideal cloud system and an ideal private system.

The practical choice is between services their existing employees can operate. CAN is betting that local support will make dedicated infrastructure manageable for organizations that would otherwise avoid it.

The Real Contest Is Dedicated Capacity Versus Cloud Flexibility

AI Workhorse challenges the cloud-first assumption, but it does not make public cloud infrastructure obsolete.

Cloud AI became the default because it lowers the barrier to experimentation. A developer can access a capable model through an application programming interface, which lets software send requests to an external service.

That approach avoids hardware purchasing, installation, cooling, and most maintenance. It also lets teams switch models, expand capacity, or end an experiment quickly.

Dedicated nodes reverse those strengths and weaknesses. Customers receive reserved capacity and more direct control, but they assume a longer commitment to particular hardware and operating decisions.

The deciding factor is often workload stability. An unpredictable pilot benefits from on-demand capacity. A steady production workflow can make dedicated computing easier to forecast and govern.

Workhorse executives argue that usage-based token expenses can become unbounded. A token is a small unit of text processed by a language model, and many commercial services meter usage through token volume.

That concern should not be treated as universal. Cloud model prices, caching options, batch processing, and smaller models continue to improve. A carefully designed cloud application can cost less than an underused private server.

Stanford’s 2025 AI Index found that the inference cost for performance comparable to GPT-3.5 fell more than 280-fold within roughly 18 months. Its inference cost analysis also showed much smaller models reaching performance levels once associated with far larger systems.

Those trends cut in two directions.

Falling model costs strengthen cloud services because customers can purchase better performance for less. The same progress strengthens private AI because smaller models can deliver useful results on more modest hardware.

Model optimization is therefore central to the Workhorse thesis. The company says specific training and tuning methods can help less expensive models perform like premium alternatives for targeted jobs.

That claim requires careful interpretation. A small model can match a larger model on a narrow, well-designed task. It does not follow that the smaller model matches every capability of the larger system.

An internal support assistant, for example, may only need to retrieve approved documents and produce structured answers. A general research agent faces wider questions and more variable reasoning demands.

The customer must define success before comparing models. Useful measures include task accuracy, latency, failed requests, human review time, and the rate of unsupported answers.

Without that evaluation, a private model can look economical while shifting work back to employees. It can also produce errors that remain hidden until a customer or regulator notices.

Cloud providers retain other advantages. They invest heavily in security engineering, reliability, model updates, and specialized chips. They also offer managed identity, monitoring, data tools, and compliance features.

A local node offers greater infrastructure control, but control carries labor. Someone must patch operating systems, update model-serving software, test new versions, and manage backups.

Workhorse attempts to close that gap by combining hardware with CAN’s engineers and Scott Data’s operations. The product is therefore closer to a managed private AI service than a simple server sale.

That distinction will determine whether the company can compete. Many organizations want control without becoming infrastructure operators. Workhorse succeeds only if its service makes that combination credible.

Scott Data Gives the Local AI Model a Head Start

Workhorse is more plausible because it can use an existing Omaha data center instead of building a new facility around an untested startup.

Scott Data has operated in Omaha since 2002. The organization describes its facility as a Tier III-certified data center with redundant power, cooling, security controls, and support for high-density computing.

Its AI infrastructure includes colocation, high-performance computing, and GPU services. Graphics processing units, or GPUs, are chips designed to handle the parallel calculations used by many AI models.

Scott Data says its facility covers 110,000 square feet and uses a 20-megawatt central plant. It also supports traditional air cooling while preparing more advanced liquid-cooling options for dense equipment.

Those figures describe Scott Data’s broader facility, not the capacity reserved for Workhorse. Neither organization has disclosed how many nodes the startup can deploy within that environment.

The partnership still removes a major obstacle. Data centers require significant investment in power delivery, cooling, physical security, networking, and backup systems.

A startup that built those systems from scratch would face a much larger financing and execution burden. Workhorse can instead focus on node design, model deployment, and customer support.

Scott Data already participates in Omaha’s broader AI strategy. It has worked with the Greater Omaha Chamber to help local companies explore AI and access computing resources.

The data center also partnered with the University of Nebraska-Lincoln on an AI makerspace. That facility gives engineering students access to eight Nvidia H100 GPUs for building and testing projects.

These efforts create a small regional pipeline around computing, education, and business adoption. Workhorse adds a product aimed at organizations ready to move beyond experimentation.

The regional model also contrasts with the hyperscale data center race. Hyperscale facilities support enormous cloud platforms and can consume large amounts of land, electricity, water, and specialized equipment.

Nebraska already faces questions about how future data center and industrial demand will affect its electric grid. Those constraints make targeted use of existing capacity more attractive than treating every AI strategy as a construction project.

At a 2025 regional discussion, Scott Data CEO Ken Moreano said some large companies initially requested dozens of GPUs. After examining the workloads, he said they sometimes needed only a few.

That observation, reported in an analysis of Omaha AI infrastructure, supports a smaller-node strategy. It also needs case-by-case verification.

Companies routinely overestimate or underestimate computing demand during early planning. A successful pilot can also grow beyond the capacity of its original node.

Workhorse will need a clear expansion path. Customers should understand whether they can add GPUs, connect several nodes, move workloads, or use cloud capacity during demand spikes.

This is where hybrid infrastructure may become more useful than an absolute local-versus-cloud choice. A company can keep sensitive retrieval and records on controlled infrastructure while using outside services for approved tasks.

Workhorse does not need to replace every cloud workload. It needs to identify the applications where local control and steady capacity justify a dedicated environment.

What AI Workhorse Has Not Proved Yet

Workhorse has a coherent response to enterprise concerns, but the public evidence remains too limited to confirm its security or economic advantages.

The company has not disclosed its standard hardware specifications. Buyers cannot publicly compare processor type, memory, storage, network speed, energy use, or expected model performance.

Workhorse also has not published benchmark results. There is no independent comparison showing how its nodes perform against cloud services on common enterprise tasks.

Security information remains equally limited. Scott Data describes physical and operational protections, but Workhorse has not released a product-specific security architecture or external assessment.

Important questions include encryption, tenant isolation, administrative access, patch schedules, log retention, backup procedures, and incident response. Customers should also know who can access model files and system prompts.

A dedicated machine does not necessarily mean a fully isolated system. It can still connect to shared networks, remote administration tools, software repositories, and customer databases.

The company’s claim that a customer can identify the physical home of its model is useful. Security teams need a complete data-flow diagram in addition to that location.

The economic case also needs real utilization data. Dedicated capacity works best when customers use enough of it to justify ongoing operation.

A low-volume application may remain cheaper in the cloud. A high-volume but irregular application may need elasticity that one node cannot provide.

Model progress creates hardware risk as well. New chips and more efficient models can change the preferred infrastructure before older equipment reaches the end of its useful life.

Cloud customers receive many upgrades through service changes. Private infrastructure customers need contracts explaining upgrade options, migration assistance, and responsibility for outdated components.

Customer secrecy creates another verification problem. Workhorse says security prevents it from naming current clients. That is understandable, but outside observers still need evidence of production reliability.

The company could eventually publish anonymized workload profiles. It could report uptime, utilization, task accuracy, deployment time, or support volume without revealing customer identities.

Third-party security reviews would strengthen the pitch. So would independently reproduced performance tests using clearly defined models and workloads.

The nonprofit donation program needs similar follow-through. Workhorse says it will donate a node after every five commercial node purchases, with training and support included.

That model connects infrastructure growth to community access. It also assumes nonprofits can identify appropriate use cases, prepare data, establish governance, and support staff participation.

A free server does not solve those organizational requirements. The training offered through CAN and the Omaha Data Science Academy may prove more important than the hardware itself.

Nonprofits often manage sensitive information about donors, employees, patients, students, or vulnerable communities. They need the same security and evaluation discipline expected from commercial customers.

The strongest version of the donation program would pair each node with a bounded project, responsible staff, access policies, and measurable outcomes.

Until those results emerge, Workhorse should be viewed as an early managed-infrastructure experiment. Its promises are plausible, but they remain company claims.

Three Signals Will Show Whether Private AI Works in Nebraska

Workhorse’s next test is not whether it can assemble more servers. It is whether customers can run valuable workloads with measurable control and predictable effort.

The first signal is repeat production use. Workhorse needs customers that renew, expand capacity, or move additional workflows onto their nodes.

A growing client count alone would say little. Repeat usage would show that dedicated infrastructure solves a continuing problem rather than satisfying temporary curiosity.

The most useful evidence would connect each deployment to a defined task. That might include faster document review, lower support backlogs, improved analyst throughput, or reduced dependence on outside endpoints.

The second signal is independent security and performance validation. Workhorse should publish enough technical detail for buyers to compare its nodes with cloud and on-premises alternatives.

That does not require exposing customer data or proprietary configurations. It requires clear test conditions, model names, hardware information, and repeatable measurements.

Security validation should cover more than the data center building. It should examine node configuration, identity controls, remote access, software updates, logging, and recovery procedures.

A credible audit would strengthen the company’s claim that local infrastructure offers greater control. A serious incident or unclear responsibility would weaken it.

The third signal is evidence that the community model functions. Donated nodes should lead to deployed nonprofit services, trained employees, and documented safeguards.

This signal matters because Workhorse presents itself as more than a private computing vendor. It wants commercial demand to build shared regional AI capacity.

That vision fits Nebraska’s existing combination of local businesses, universities, consultants, and nonprofit infrastructure. It also faces a common regional challenge: turning available technology into sustained organizational capability.

Hardware can sit idle. Models can disappoint users. Pilot projects can fail when their original champion leaves.

Organizations considering private AI should begin with the workflow, not the node. They should identify sensitive data, current labor, expected request volume, accuracy requirements, and acceptable failure modes.

They should compare at least three deployment patterns: managed cloud AI, dedicated private infrastructure, and a hybrid design. Each option should face the same security, quality, and operating questions.

Teams also need a reliable information layer. A searchable knowledge base can help organize approved documents before any model retrieves them.

AI Workhorse has made Nebraska a useful test case for the private AI argument. The next few months should reveal whether local nodes deliver operational control or simply relocate familiar complexity.

For enterprise buyers, the right next action is direct: select one repeatable workflow, document its risk boundary, and measure it across competing infrastructure options. If Workhorse can win that comparison under real production conditions, its local model will have significance far beyond Omaha.