15. Enterprise Strategy and Emerging Programming TrendsIntroduction and ContextProgramming for data science is often introduced as a technical activity: writing Python or R code, manipulating data, training models, and communicating results. In an enterprise, however, programming choices are also strategic choices. They influence the speed of innovation, the reliability of operations, the cost of ownership, the availability of skills, regulatory exposure, and the ability of an organisation to adapt to new technologies. A data science team may select Python because it offers a broad machine-learning ecosystem, R because it supports statistical analysis and specialised research workflows, or a combination of both. It may decide to develop a forecasting platform internally, purchase a commercial product, or combine a vendor product with internally developed components. It may use a generative AI coding assistant to accelerate development, call a foundation-model API to add language capabilities to an application, or build a retrieval-augmented generation system over private organisational documents. Each choice creates value, but each also introduces technical, financial, operational, and ethical consequences. This chapter examines programming for data science from an enterprise-strategy perspective. It considers platform selection, build-versus-buy decisions, team capability, technical debt, and return on analytics investment. It then evaluates major developments in the Python and R ecosystems, generative AI coding assistants, foundation-model APIs, retrieval-augmented applications, automated data science, and synthetic data. The central argument is that emerging tools should not be adopted merely because they are fashionable. They should be selected when they contribute to measurable organisational outcomes and can be governed responsibly. Learning ObjectivesAfter completing this chapter, the student should be able to: 1. Evaluate Python, R, and platform alternatives in relation to enterprise requirements. 2. Apply a structured build-versus-buy framework to data-science initiatives. 3. Explain how team capability, technical debt, and architecture affect long-term value. 4. Design a balanced approach to measuring return on analytics investment. 5. Critically assess generative AI coding assistants and foundation-model APIs. 6. Explain the architecture, uses, and limitations of retrieval-augmented applications. 7. Evaluate automated data science and synthetic data for suitable use cases. 8. Recommend governance and implementation practices for emerging programming technologies. From Programming Tool to Enterprise CapabilityAn enterprise programming environment consists of more than a language. It includes libraries, development tools, data platforms, deployment mechanisms, security controls, testing practices, monitoring systems, and people. A language becomes strategically useful when an organisation can use it repeatedly and reliably across the analytics lifecycle. Python has become prominent because one language can support data ingestion, exploratory analysis, machine learning, web services, automation, and application integration. Libraries such as pandas, NumPy, scikit-learn, PyTorch, TensorFlow, FastAPI, and many cloud SDKs support a wide range of activities. Python is also strongly represented in artificial intelligence and production software engineering. Its disadvantages may include dependency complexity, inconsistent environments, performance limitations in poorly designed code, and the need for disciplined packaging and testing. R remains highly important for statistical modelling, experimental analysis, epidemiology, econometrics, survey research, and academic or regulated analytical work. Its packages support specialised methods, statistical inference, visualisation, and reproducible reporting. The tidyverse provides a coherent approach to data manipulation and communication, while tools such as Shiny can transform analyses into interactive applications. R may be less convenient than Python for general-purpose application engineering and some production integration scenarios, although modern deployment tools reduce this gap. The choice between Python and R should therefore be based on the complete operating context rather than on popularity. Relevant questions include: - What types of models and analyses are required?
- What skills are already available within the organisation?
- Must models be embedded in transaction-processing applications?
- What are the requirements for statistical inference, reproducibility, and auditability?
- Which languages are supported by existing deployment and security platforms?
- Can the organisation maintain packages, environments, pipelines, and documentation over several years?
A hybrid strategy is often appropriate. For example, a research team may use R for statistical investigation and Python for model serving, or both languages may be exposed through APIs. The cost of a hybrid environment is additional integration and governance. The benefit is that teams can use the most suitable tool for each task. A hybrid approach is valuable only when interfaces, ownership, documentation, and deployment standards are clearly defined. A Strategic Framework for Platform SelectionPlatform selection can be evaluated through five dimensions: business fit, technical fit, operational fit, organisational fit, and governance fit. Business fit asks whether the platform supports a meaningful business capability. A technically impressive platform that does not improve decisions, reduce cost, increase revenue, or reduce risk has weak strategic justification. The expected users, decision cycle, service-level requirements, and financial benefits should be explicit. Technical fit concerns data formats, model types, interoperability, scalability, latency, integration, and performance. A platform designed for batch forecasting may be unsuitable for real-time fraud detection. A language that supports prototyping may not automatically satisfy production reliability requirements. Operational fit includes deployment, monitoring, incident response, version control, testing, backup, disaster recovery, and support. Data science projects frequently fail during the transition from notebook to production because operational needs were not considered at the beginning. Organisational fit concerns skills, team structure, training, recruitment, supplier dependence, and the ability to provide long-term ownership. A platform requiring rare expertise may create significant concentration risk. Governance fit includes privacy, access control, data residency, explainability, audit trails, intellectual-property protection, and regulatory obligations. Governance is not an administrative activity added after development; it is part of the platform design. A useful selection process begins with requirements rather than products. The organisation should define decision problems, users, data constraints, expected scale, risk tolerance, and success measures. Candidate platforms can then be assessed using weighted criteria. A simple scoring matrix is useful, but scores should be supported by prototypes and evidence. A small proof of concept may reveal integration or operational problems that a paper comparison hides. Build, Buy, or Compose?The build-versus-buy decision is not a binary choice. Organisations can build a complete system internally, purchase a complete product, or compose a solution from managed services, open-source components, and proprietary code. Building internally is attractive when the capability is strategically differentiating, when requirements are highly specific, or when sensitive data and intellectual property cannot be entrusted to an external provider. It also permits detailed control over architecture. Its disadvantages include higher initial cost, longer delivery time, recruitment challenges, maintenance obligations, and the risk that a prototype becomes an unsupported operational system. Buying is attractive when the problem is common, the supplier has mature support, and rapid implementation is important. Commercial products may include security features, user management, monitoring, documentation, and service-level commitments. Nevertheless, purchasing creates supplier dependence, recurring costs, limited customisation, migration risk, and possible restrictions on data or model portability. Composition often provides a practical middle path. An organisation might purchase cloud infrastructure, use open-source machine-learning libraries, call a foundation-model API, and develop its own domain-specific workflow and user interface. This concentrates internal effort on the parts that create differentiation while delegating commoditised components to specialists. A structured decision should consider: 1. Strategic differentiation: Is this capability central to competitive advantage? 2. Total cost of ownership: What are development, licensing, integration, training, monitoring, support, and exit costs? 3. Time to value: How quickly must the capability be operational? 4. Risk and compliance: What privacy, security, resilience, and regulatory conditions apply? 5. Flexibility: Can the solution adapt to new data, models, users, and regulations? 6. Capability development: Will the choice strengthen or weaken internal expertise? 7. Exit feasibility: Can data, workflows, and models be transferred if the supplier changes terms? The apparent low cost of a purchased service may be misleading if integration, data preparation, customisation, and governance are excluded. Similarly, the apparent control of an internally built system may be misleading if the organisation cannot maintain it. Total cost of ownership must include the full life cycle rather than only initial development. Team Capability, Architecture, and Technical DebtEnterprise analytics is a socio-technical capability. A successful team requires more than data scientists. Depending on the initiative, it may include data engineers, machine-learning engineers, software developers, cloud or platform engineers, domain specialists, product managers, security professionals, legal advisers, and responsible-AI specialists. Team design should balance specialisation and collaboration. Excessive specialisation can create hand-off delays, while a team with no specialised expertise may produce fragile solutions. Cross-functional teams are especially valuable when models affect customers, employees, financial decisions, or public services. Domain experts help define valid outcomes and identify implausible results; engineers make systems reliable; data scientists develop analytical methods; and product leaders connect technical work to organisational value. Technical debt is the future cost created when a system is developed with shortcuts, inadequate documentation, weak testing, obsolete dependencies, poor data quality, or unsuitable architecture. Some debt is deliberate: a team may release a limited pilot to test demand. Such debt is acceptable only when it is recorded, assessed, and repaid. Accidental debt arises when temporary code is treated as permanent or when the consequences of a decision are not understood. In data science, technical debt has distinctive forms. Data dependencies may be undocumented; labels may change over time; training data may no longer represent current conditions; notebooks may contain untested logic; models may be impossible to reproduce; and monitoring may not detect drift. A model can therefore remain mathematically valid while its business performance deteriorates. Technical debt should be managed as a portfolio issue. Teams can maintain an architecture register, assign ownership to data assets and models, automate testing, pin and scan dependencies, document assumptions, and schedule refactoring. A useful principle is that production systems should have a higher engineering standard than exploratory work. Not every notebook needs enterprise controls, but every operational service does. Measuring Return on Analytics InvestmentReturn on analytics investment is more complex than dividing financial benefit by project cost. Analytics often changes decisions rather than producing a separate revenue stream. A customer-retention model, for example, creates value only if the organisation contacts the right customers, offers an effective intervention, and avoids excessive incentive costs. A benefits model should distinguish between direct, indirect, and enabling value. Direct value may include reduced fraud losses, lower inventory costs, increased conversion, or reduced processing time. Indirect value may include improved customer experience or better employee decision-making. Enabling value includes reusable data assets, improved capability, and faster delivery of future initiatives. A practical evaluation can use the following logic: Net value = realised benefits − total life-cycle costs Life-cycle costs include data acquisition, engineering, development, licences, infrastructure, training, integration, monitoring, governance, support, and model retirement. Benefits should be estimated using a baseline or control group whenever possible. If a model changes an operational decision, the evaluation should compare outcomes with and without that decision intervention. Metrics should be defined at several levels: - Technical: latency, uptime, error rate, reproducibility, and model drift.
- Analytical: predictive performance, calibration, stability, and fairness indicators.
- Operational: adoption, workflow completion, response time, and automation rate.
- Business: profit, cost reduction, risk reduction, retention, quality, or productivity.
- Strategic: capability reuse, time to launch, and organisational learning.
A common mistake is to treat model accuracy as business value. A highly accurate model may have little impact if users do not trust it, if its predictions arrive too late, or if no operational action follows. Conversely, a moderately accurate model may be valuable when it improves a high-volume decision at low cost. Generative AI Coding Assistants and Foundation-Model APIsGenerative AI coding assistants can suggest code, explain functions, generate tests, translate between languages, identify possible errors, and help users explore unfamiliar libraries. They can reduce the effort required for routine programming and may improve accessibility for analysts who are developing software skills. Their output, however, is probabilistic. It may be syntactically correct but logically wrong, insecure, inefficient, or inconsistent with organisational standards. A coding assistant should be treated as an accelerator, not as an authority. Professional practice requires developers to review generated code, run tests, inspect dependencies, verify licences, and protect confidential information. Generated code can reproduce insecure patterns or make unsupported assumptions about data. In data science, an assistant may produce a plausible analysis with incorrect joins, leakage between training and test data, inappropriate evaluation metrics, or misleading visualisations. Foundation models are large models trained on broad data and adapted for tasks such as language generation, summarisation, classification, code generation, image analysis, or conversational interaction. An organisation can use a model through an API rather than training one from scratch. APIs reduce infrastructure requirements and provide rapid access to advanced capabilities, but they create dependence on provider availability, pricing, version changes, usage policies, and data-handling arrangements. Before using a foundation-model API, an organisation should clarify: - Whether prompts and outputs are retained by the provider.
- Where data is processed and stored.
- Whether confidential or personal information may be submitted.
- How model versions and behaviour changes are communicated.
- What limits, latency, and availability guarantees apply.
- Whether outputs can be used commercially and how intellectual property is treated.
- How errors, harmful content, and unsupported claims will be detected.
Prompt engineering may improve results, but it is not a substitute for evaluation. Reliable applications require representative test sets, explicit output schemas, validation rules, human review where appropriate, and monitoring after deployment. Structured outputs and tool calling can make a model easier to integrate, but they do not guarantee factual correctness. Retrieval-Augmented ApplicationsA retrieval-augmented generation (RAG) application combines information retrieval with a generative model. Instead of asking a model to answer solely from its training knowledge, the system retrieves relevant organisational documents or records and includes them in the model’s context. The model then generates an answer based partly on the retrieved evidence. A typical RAG pipeline contains document ingestion, extraction, cleaning, chunking, embedding, indexing, retrieval, prompt construction, generation, and response evaluation. Documents may be stored in a vector database, a keyword index, or a hybrid system. Hybrid retrieval can combine semantic similarity with exact keyword matching, which is useful for names, product codes, legal clauses, and technical identifiers. RAG is useful for internal knowledge assistants, policy search, technical support, research discovery, and document question answering. Its principal advantage is that knowledge can be updated by changing the indexed material rather than retraining the foundation model. It can also support citations or document references, improving traceability. RAG does not eliminate hallucination. Retrieval may fail because the document is missing, poorly indexed, incorrectly chunked, or inaccessible under the user’s permissions. The model may misinterpret evidence or combine passages incorrectly. Security design must ensure that retrieval respects document-level access controls; otherwise, a user could obtain information that the underlying repository would not normally reveal. Evaluation should separately measure retrieval quality and answer quality. Retrieval metrics may consider whether relevant documents appear in the top results. Answer evaluation may assess correctness, completeness, groundedness, citation accuracy, harmfulness, and refusal behaviour. A RAG system should also have a clear response when evidence is insufficient rather than generating a confident unsupported answer. Automated Data Science and Synthetic DataAutomated data science, often associated with automated machine learning, uses software to automate parts of data preparation, feature selection, model selection, hyperparameter optimisation, and evaluation. It can help teams establish baselines, compare algorithms, and accelerate routine modelling. It is especially useful when many similar datasets or standard prediction problems must be analysed. Automation does not replace problem formulation. A system may optimise an inappropriate target, use a biased sample, leak information from the future, or select a model that performs well on historical data but poorly after deployment. Human expertise remains necessary for defining the prediction moment, selecting valid labels, interpreting constraints, assessing fairness, and planning operational use. Synthetic data is artificially generated data designed to resemble selected properties of real data. It may be produced using statistical models, simulation, generative models, or combinations of these methods. Potential uses include software testing, education, sharing data with reduced disclosure risk, balancing rare classes, and developing prototypes when access to real data is restricted. Synthetic data is not automatically anonymous or representative. A generator may memorise unusual records, reproduce social bias, omit important minority patterns, or create unrealistic relationships. Its utility should be evaluated against the intended analytical task, while privacy assessment should consider linkage and re-identification risks. Synthetic data should not be used to conceal poor data quality or to claim that a model has been validated on real-world conditions when it has not. Illustrative Case: A Retail Bank’s Analytics Platform DecisionBackgroundA fictional retail bank, Meridian Bank, wants to improve early identification of customers likely to experience payment difficulty. It has analysts using R for statistical reporting, data scientists using Python for machine learning, and a central technology team operating cloud services. Senior management proposes purchasing an automated AI platform to accelerate delivery. Situation and ProblemThe bank must decide whether to build an internal modelling service, purchase a commercial platform, or compose a solution. The system will influence customer contact and therefore requires explainability, auditability, privacy protection, and monitoring. Management also wants measurable evidence of financial and social value. AnalysisA full build would provide flexibility but would require substantial engineering, security, and support capability. A complete purchased platform would accelerate implementation but might restrict model portability and make it difficult to explain supplier-specific behaviour. The team identifies reusable internal capabilities—data definitions, validation rules, governance processes, and decision monitoring—as strategically important. Commodity infrastructure and experiment tracking can be obtained as managed services. The team also examines language choice. R is retained for some statistical validation and reporting because analysts already possess strong expertise. Python is selected for the production service because it integrates with the bank’s existing application interfaces and machine-learning deployment standards. The two environments exchange validated datasets and documented model artefacts rather than relying on informal manual transfer. Approach and StrategyThe bank chooses a composed architecture. It builds domain-specific feature definitions, policy rules, monitoring, and customer-intervention logic internally. It purchases managed infrastructure and uses established open-source libraries under an approved dependency process. An automated machine-learning tool is used to generate candidate baselines, but the final model is selected through human review. A pilot is evaluated using a controlled operational design. The bank measures not only predictive performance but also contact effectiveness, customer outcomes, complaint rates, fairness indicators, staff adoption, and total operating cost. A model card records intended use, limitations, data sources, evaluation results, and approval status. A retirement condition is defined in advance if performance or fairness deteriorates. Generative AI is used only for low-risk developer assistance and documentation drafts. Customer data is excluded from external prompts unless an approved protected service is used. A RAG assistant is later introduced for internal policy search, with document-level access controls and citations. OutcomeThe composed strategy gives the bank faster delivery without surrendering control over critical decisions. It also reveals that the largest value comes from improving intervention design and data quality rather than from selecting the most complex algorithm. The pilot establishes a repeatable governance pattern for later analytics initiatives. Learning PointsThe case illustrates that platform decisions should be based on strategic differentiation and life-cycle capability. Hybrid language use can be effective when interfaces and ownership are explicit. Automated tools accelerate candidate development but do not replace judgement. Finally, analytics value must be measured at the level of changed decisions and customer outcomes, not only model metrics. Risks, Governance, and Professional PracticeEmerging programming technologies create risks involving privacy, security, bias, intellectual property, inaccurate outputs, supplier concentration, and unequal access. Governance should be proportionate to risk, but high-impact applications require stronger controls than internal experimentation. Organisations should classify use cases by impact, restrict sensitive data, maintain access controls, log important interactions, document models and prompts, test for failure modes, and establish human accountability. Model and application owners should be identifiable. Users should know when they are interacting with an automated system where that knowledge affects trust or decision-making. Data protection principles such as purpose limitation, data minimisation, accuracy, retention control, and lawful processing remain relevant when AI tools are used. Security reviews should address prompt injection, malicious documents, data exfiltration, insecure generated code, dependency vulnerabilities, and excessive permissions. For regulated decisions, explanation, contestability, record keeping, and auditability may be essential. Common professional mistakes include adopting a tool before defining the problem, measuring only accuracy, treating open-source software as cost-free, ignoring exit costs, exposing confidential information in prompts, allowing generated code into production without review, and assuming that retrieved documents guarantee truthful answers. Strong practice combines experimentation with controls: sandbox new tools, use approved data, evaluate representative cases, review outputs, and expand deployment only when evidence supports it. Emerging Directions in Python and RThe Python and R ecosystems are increasingly connected to cloud platforms, notebooks, application programming interfaces, distributed processing, and machine-learning operations. Python development is moving toward stronger packaging, reproducible environments, typed interfaces, accelerated numerical computation, and closer integration between data engineering and application engineering. R continues to develop as a platform for reproducible analysis, interactive communication, statistical modelling, and publication-quality reporting. Interoperability is likely to remain more important than language rivalry. Columnar data formats, database engines, APIs, shared model formats, and workflow orchestration allow teams to combine tools. The strategic question is not which language wins, but how an organisation prevents fragmented practices while preserving analytical flexibility. Future data-science programming will also involve more natural-language interfaces, automated code generation, multimodal models, local or specialised models, privacy-preserving computation, and software agents that execute multi-step tasks. These developments may improve productivity, but they also increase the importance of testing, provenance, permissions, and human oversight. As tools become easier to use, the scarce capability may shift from writing individual lines of code to framing problems, evaluating evidence, designing systems, and accepting accountability for outcomes. Chapter SummaryEnterprise programming choices are strategic because they shape cost, speed, resilience, skills, governance, and long-term adaptability. Python and R should be selected according to business, technical, operational, organisational, and governance requirements; a well-managed hybrid approach is often appropriate. Build-versus-buy decisions should consider strategic differentiation, total cost of ownership, time to value, risk, capability development, flexibility, and exit feasibility. Analytics value depends on changed decisions and realised outcomes rather than model accuracy alone. Technical debt, weak documentation, data drift, and fragile deployment can reduce value even when an analysis is initially successful. Generative AI coding assistants and foundation-model APIs can accelerate development, but their outputs require review, testing, security controls, and intellectual-property safeguards. RAG systems connect retrieval with generation and can improve access to organisational knowledge, yet they require careful indexing, permission management, and evaluation. Automated data science and synthetic data are useful accelerators when their assumptions, limitations, privacy implications, and representativeness are examined. The enduring enterprise skill is responsible system design: selecting appropriate tools, measuring consequences, and maintaining accountability. Key TermsAnalytics return on investment: The net organisational value generated by analytics relative to its total life-cycle cost. Automated machine learning: Software-assisted automation of tasks such as feature processing, model selection, and hyperparameter optimisation. Build-versus-buy decision: A structured choice between developing a capability internally, acquiring it from a supplier, or composing both approaches. Coding assistant: A generative AI tool that supports programming through code suggestion, explanation, testing, or translation. Foundation model: A broadly trained model adapted for multiple downstream tasks through prompting, fine-tuning, or tool integration. Hybrid architecture: An architecture that combines multiple languages, platforms, services, or deployment methods. Model drift: A change in data, relationships, or outcomes that causes deployed model performance or validity to deteriorate. Retrieval-augmented generation: An application pattern in which retrieved information is supplied to a generative model to support an answer. Synthetic data: Artificially generated data intended to reproduce selected properties of real data. Technical debt: Future cost and reduced flexibility caused by shortcuts, weaknesses, or deferred maintenance in a technical system. Total cost of ownership: All costs incurred across acquisition, development, operation, maintenance, governance, and retirement. Vector database: A system that stores and searches numerical representations of items using similarity relationships. Model card: A document describing a model’s purpose, data, performance, limitations, and intended use. Data leakage: The unintended use of information in model development that would not be available at prediction time. Interoperability: The ability of different systems, languages, or components to exchange and use information effectively. Groundedness: The extent to which a generated response is supported by available evidence. Supplier lock-in: Difficulty or cost associated with moving away from a technology provider or platform. Technical capability: The combination of skills, tools, processes, and infrastructure needed to deliver and sustain a technical function. Review QuestionsShort Answer Questions1. Why should Python and R selection be treated as an enterprise capability decision rather than only a language preference? 2. Define technical debt and give two examples specific to data-science systems. 3. What is retrieval-augmented generation, and why does it not eliminate hallucination? 4. Identify four categories of metrics that can be used to assess analytics value. 5. State two risks associated with generative AI coding assistants. Long Answer Questions1. Explain a comprehensive framework for selecting a data-science platform in an enterprise. 2. Compare building, buying, and composing an analytics capability, including total cost and strategic implications. 3. Discuss the roles of data scientists, engineers, domain specialists, product managers, and governance professionals in an enterprise analytics team. 4. Explain how automated data science and synthetic data can be used responsibly, including their limitations. 5. Analyse the governance requirements for foundation-model APIs and retrieval-augmented applications. Analytical / Application Questions1. An organisation has strong R expertise, an expanding Python engineering team, and a requirement to deploy models within customer-facing applications. Recommend a language and integration strategy, justifying the trade-offs. 2. A generative AI assistant produces code that passes basic tests but uses customer identifiers in an external API request. Identify the risks and design a safer development and review process. 3. A company reports a highly accurate churn model but observes no reduction in churn. Diagnose possible reasons using the concepts of operational adoption, intervention design, technical debt, and return on analytics investment. 22. Multiple Choice Questions with AnswersQuestion 1Which consideration most directly distinguishes an enterprise platform decision from a personal programming-language preference? A. The colour scheme of the development environment B. The platform’s fit with business objectives, operations, governance, and available skills C. The number of lines of code written during a prototype D. The programming language used by a competing organisation Correct Answer: B. The platform’s fit with business objectives, operations, governance, and available skills Question 2An organisation wants rapid delivery but also needs control over domain-specific decision logic and monitoring. Which strategy is most appropriate? A. Build every infrastructure component internally B. Purchase a complete product without customisation C. Compose managed services with internally developed differentiating components D. Avoid using any external software Correct Answer: C. Compose managed services with internally developed differentiating components Question 3Which is an example of technical debt in a data-science system? A. A documented model with automated tests B. A temporary notebook becoming an undocumented production workflow C. A version-controlled dependency update D. A scheduled model review Correct Answer: B. A temporary notebook becoming an undocumented production workflow Question 4Why is model accuracy alone an insufficient measure of analytics return on investment? A. Accuracy can never be calculated for a model B. Accuracy does not show whether users act on predictions or whether outcomes improve C. Accuracy is relevant only to unsupervised learning D. Accuracy automatically includes infrastructure cost Correct Answer: B. Accuracy does not show whether users act on predictions or whether outcomes improve Question 5What is the principal role of retrieval in a retrieval-augmented generation application? A. To retrain the foundation model after every user question B. To supply relevant external or organisational information to support generation C. To guarantee that every generated answer is correct D. To replace access-control mechanisms Correct Answer: B. To supply relevant external or organisational information to support generation Question 6A coding assistant generates syntactically valid code that accidentally leaks information through an external API. What is the most appropriate professional response? A. Deploy it because the syntax is valid B. Review, test, and security-check generated code before approval C. Assume the API provider will correct the problem D. Remove all testing to preserve development speed Correct Answer: B. Review, test, and security-check generated code before approval Question 7Which condition is especially important when evaluating synthetic data? A. Whether it has a visually attractive format B. Whether it preserves utility while avoiding unacceptable disclosure and bias C. Whether it contains exactly the same records as the source data D. Whether it eliminates the need for real-world validation Correct Answer: B. Whether it preserves utility while avoiding unacceptable disclosure and bias Question 8In the Meridian Bank case, why was Python selected for the production service while R remained in use? A. R cannot perform statistical analysis B. Python fit existing application and deployment interfaces, while R retained value for statistical work C. Python requires no governance D. The bank prohibited all hybrid architectures Correct Answer: B. Python fit existing application and deployment interfaces, while R retained value for statistical work Question 9Which practice best reduces supplier lock-in when using a foundation-model API? A. Relying on undocumented provider-specific behaviour B. Avoiding all interface abstraction C. Documenting interfaces, data handling, model assumptions, and feasible exit options D. Sending all organisational data to one provider Correct Answer: C. Documenting interfaces, data handling, model assumptions, and feasible exit options Question 10What is a major reason automated machine learning cannot replace human expertise? A. It cannot compare any models B. It cannot define valid business targets, prediction contexts, ethical constraints, and operational use by itself C. It never performs data preparation D. It is useful only for visualisation Correct Answer: B. It cannot define valid business targets, prediction contexts, ethical constraints, and operational use by itself
|
